Results 1 to 16 of 16

Thread: Pixmap in translucent QLabel overlay, distorts screen

  1. #1
    Join Date
    Nov 2016
    Location
    Florida, US
    Posts
    26
    Thanks
    7
    Qt products
    Qt5
    Platforms
    Unix/X11

    Default Pixmap in translucent QLabel overlay, distorts screen

    New to QT, and suspect I have a case where I am breaking some rule, or using a bad approach. I realize code would be best, but I have not found a good way to reduce this to a complete, postable example, so with apologies in advance I will try to provide enough code snippets to explain.

    First, let me show you the result. Please see two screen shots attached, one that worked, one that has the failure. They are a display of sheet music, with a momentary overlay showing areas of the screen in color. As you can see, one shows a badly distorted image. At times it is much more distorted than you see here, where the colored areas are not even clearly distinguished.

    The only difference in these two is a delay in creating the overlay (the delay lets it work).

    The Underlying screen structure, before the overlay, looks like this (nesting shown by indents, abbreviated):

    Qt Code:
    1. QWidget* outerLayoutWidget; // outer widget set as central widget in window to hold layout
    2. QVBoxLayout* outerLayout;
    3. QWidget* menuLayoutWidget;
    4. QHBoxLayout* menuLayout;
    5. QWidget* mainMenuLayoutWidget;
    6. QHBoxLayout* mainMenuLayout;
    7. QPushButton* libraryButton;
    8. ...
    9. QWidget* playerMenuLayoutWidget;
    10. QHBoxLayout* playerMenuLayout;
    11. QPushButton* playButton;
    12. QPushButton* firstButton;
    13. ....
    To copy to clipboard, switch view to plain text mode 
    This resides in a QMainWindow class, and outerLayoutWidget is set as the central widget. The various widgets are hidden and visible as needed, and seem to work fine as activity occurs.

    At one point I want to overlay the entire screen (i.e. mainwindow) with a painted overlay for a few seconds. This occurs in code (as action from a button press) which creates quite a few new widgets inside of outerLayout (and with outerLayoutWidget as parent), and then I do this (the variable overlay is defined in the mainwindow class header to match the TipOverlay class).

    Qt Code:
    1. overlay = new TipOverlay(outerLayoutWidget);
    2. overlay->show();
    To copy to clipboard, switch view to plain text mode 

    TipOverlay.h (irrelevant stuff edited):
    Qt Code:
    1. class TipOverlay : public QLabel
    2. {
    3. Q_OBJECT
    4. private:
    5. QWidget* p; // parent;
    6.  
    7. public:
    8. TipOverlay(QWidget* parent); // Call with the widget to overlay
    9. ~TipOverlay();
    10. };
    To copy to clipboard, switch view to plain text mode 

    and in that routine I do a lot of painting into a pixmap and display it (again, simplified a bit)

    Qt Code:
    1. TipOverlay::TipOverlay(QWidget* parent) : QLabel(parent)
    2. {
    3. assert(parent);
    4. p = parent;
    5. this->setGeometry((p->geometry()));
    6. QPixmap tmpPix = QPixmap(p->size());
    7. QPainter painter(&tmpPix);
    8. painter.setOpacity(0.4); // For panels
    9. painter.setFont(QFont("Arial",36,1,false));
    10. .... lots of painting and text code
    11. this->setPixmap(tmpPix);
    12. this->show();
    13. QTimer::singleShot(MUSICALPI_OVERLAY_DURATION / 2,this, // Must be >= duration above
    14. [=]
    15. {
    16. ... nothing here now, eventually animation change
    17. }
    18. );
    19. QTimer::singleShot(MUSICALPI_OVERLAY_DURATION,this, // Must be >= 2* duration above
    20. [=]
    21. {
    22. ... nothing here now, eventually animation change
    23. this->deleteLater();
    24. }
    25. );
    26.  
    27. }
    To copy to clipboard, switch view to plain text mode 

    I originally had animation in this to fade in and out which I thought may be the problem but have stripped it out. The timers right now only call the deleteLater() to remove it.

    As shown above, it almost always gives the distorted view. On a subsequent iteration of the code, however, it works (due to buffering of the images a subsequent iteration takes less computation to produce the underlying screen). Because of this I introduced a half second delay before calling the "new TipOverlay" -- works every time.

    Just to be clear, just before the overlay is created (and without releasing control back to the event processor) the underlying screen has been changed - widgets hidden, background color changed, images resized and overlay is the last thing before releasing control.

    Incidentally, when the timer runs and the overlay deletes itself, the underlying screen is always displayed correctly, i.e. the distortion is not actually a corruption of the rest of the screen.

    Also, if I set opacity to 1 in the overlay, that part painted works fine -- it is the partially-see-through portions that are at issue.

    This leads me to think I am doing something wrong in creating and displaying the overlay widget, perhaps I need to do it in a separate event.

    I HAVE read the information on using QPainter only in a paint event, but I frankly cannot see how to do that, especially once I start using animation. Trying it in the event handler made it hang in what appeared to be a loop, I assume animation changes calling it recursively? I also have read that painting into a QPixmap object that is separately set is an exception to that rule (is it?).

    Some specific questions:

    - Am I right that painting into, and putting a pixmap in a Qlabel outside of a paint event is OK?

    - I am putting this overlay widget as a child of the outermost widget (inside the mainwindow), but am not putting it in the QVBoxLayout that other widgets are in (as I am forcing its layout with the geometry copy). Is that correct?

    - Is there anything wrong with a class inheriting from QLabel producing its own image with QPainter as I have done?

    - Noting that if painted at opacity 1, the overlay looks fine (at least the the parts painted), it is the areas transparent (unpainted) or partially transparent (painted at opacity 0.4) that are distorted -- is that supposed to work? To see-through to a just-changed widget(s) underneath? Do I need to wait in some fashion for that to be rendered before overlaying it? (If so, how to detect it is ready, as I don't want to guess with a time frame).

    I realize this is long (even without complete code) and thank anyone who just got to the bottom, but especially if you might give me a pointer where to look.
    Attached Images Attached Images

  2. #2
    Join Date
    Jan 2008
    Location
    Alameda, CA, USA
    Posts
    4,491
    Thanks
    252
    Thanked 717 Times in 707 Posts
    Qt products
    Qt5
    Platforms
    Windows Android

    Default Re: Pixmap in translucent QLabel overlay, distorts screen

    The observation that your distorted image is diagonal makes me think that you have an "off-by-one" error when writing pixels into the pixmap. That is, the length of the line that you think is correct is actually shorter, so your image is being wrapped around the borders of the pixmap and gets successively offset with each line. So the error is likely in the initial determination of the size of the pixmap to be painted vs. the size of the label into which you are placing it. The wrapping effect is likely a mismatch between the size of the pixmap and the size of the label.
    Last edited by d_stranz; 4th November 2016 at 16:21.
    <=== The Great Pumpkin says ===>
    Please use CODE tags when posting source code so it is more readable. Click "Go Advanced" and then the "#" icon to insert the tags. Paste your code between them.

  3. #3
    Join Date
    Nov 2016
    Location
    Florida, US
    Posts
    26
    Thanks
    7
    Qt products
    Qt5
    Platforms
    Unix/X11

    Default Re: Pixmap in translucent QLabel overlay, distorts screen

    Quote Originally Posted by d_stranz View Post
    The observation that your distorted image is diagonal makes me think that you have an "off-by-one" error when writing pixels into the pixmap. That is, the length of the line that you think is correct is actually shorter, so your image is being wrapped around the borders of the pixmap and gets successively offset with each line. So the error is likely in here:

    or in the initial determination of the size of the pixmap to be painted.
    It could be though since I copy the size() from the parent I don't see how the pixmap can be a different size. But the bigger reason I doubt it is that would not be impacted by introducing a half-second delay. It's also the underlying widget (as seen through the opacity 0.4) that is showing the distortion. As soon as the overlaying widget is deleted it looks fine. but the edges of the overlaying widget are not skewed.

    It really seems like a render-time issue, that some low level routine is grabbing data that maybe is not stable at the point it grabs it?

    That's why I think I may be violating some rule in terms of the sequence in which I do things.

    PS. I did just go back through the math, and it's really straightforward and based on the parent's geometry, i.e. here it is, I had just removed some to be more concise. I honestly do not think it is in here, other than indirectly due to some sequence or timing issue. But... really new to QT, maybe it is (and would love to know if there are easier ways, this seems very wordy).

    Qt Code:
    1. p = parent;
    2. overlayFullWidth = p->size().width();
    3. overlayTopHeight = 0.20 * p->size().height();
    4. overlayPanelWidth = 0.40 * overlayFullWidth;
    5. this->setGeometry((p->geometry()));
    6. QPixmap tmpPix = QPixmap(p->size());
    7. QPainter painter(&tmpPix);
    8. painter.setOpacity(0.4); // For panels
    9. painter.setFont(QFont("Arial",36,1,false));
    10. painter.setBrush(QBrush(Qt::red));
    11. painter.drawRect(0,0,overlayFullWidth,overlayTopHeight);
    12. painter.setBrush(QBrush(Qt::blue));
    13. painter.drawRect(0,overlayTopHeight,overlayPanelWidth,p->size().height() - overlayTopHeight);
    14. painter.setBrush(QBrush(Qt::green));
    15. painter.drawRect(overlayFullWidth - overlayPanelWidth,overlayTopHeight,overlayPanelWidth,p->size().height() - overlayTopHeight);
    16. painter.setOpacity(1.0);
    17. painter.setPen(QColor("red"));
    18. painter.drawText(QPoint(overlayFullWidth/2 - 50,overlayTopHeight/2),"End Play");
    19. painter.setPen(QColor("blue"));
    20. painter.drawText(QPoint(20,p->size().height() / 2),"Prior Page");
    21. painter.setPen(QColor("green"));
    22. painter.drawText(QPoint(overlayFullWidth - overlayPanelWidth + 20,p->size().height() / 2),"Next Page");
    23. this->setPixmap(tmpPix);
    24. this->show();
    To copy to clipboard, switch view to plain text mode 

  4. #4
    Join Date
    Jan 2008
    Location
    Alameda, CA, USA
    Posts
    4,491
    Thanks
    252
    Thanked 717 Times in 707 Posts
    Qt products
    Qt5
    Platforms
    Windows Android

    Default Re: Pixmap in translucent QLabel overlay, distorts screen

    Ah, I misunderstood. I thought your score was the overlay, not the colored rectangles. Nonetheless, I think that something you are doing is changing the size of the area into which the score is being painted and that is resulting in the aliasing effect. It may not be something you yourself are doing in code, but a resize / relayout that is occurring behind the scenes when you display the semi-transparent overlay.

    Try installing an event filter so you can watch the paint events on the QLabel so you can see if the size is changing. I'd use qDebug() rather than breakpoints so you don't interrupt the painting.
    <=== The Great Pumpkin says ===>
    Please use CODE tags when posting source code so it is more readable. Click "Go Advanced" and then the "#" icon to insert the tags. Paste your code between them.

  5. #5
    Join Date
    Nov 2016
    Location
    Florida, US
    Posts
    26
    Thanks
    7
    Qt products
    Qt5
    Platforms
    Unix/X11

    Default Re: Pixmap in translucent QLabel overlay, distorts screen

    I'm doing another overlay for another purpose and digging into it, but so far no strangeness. But I'm not using translucent either, which I think is a key here. I'll go back to the problem one shortly once I get the code all working again.

    I have a bunch of debug statements in now in all routines I have, but adding some explicit event traps is a good idea. I'm not completely sure I know what I am looking for though.

    Can you (or someone) answer one question from above -- is it indeed OK to paint into a QPixmap that is then "setpixmap()" into a QLabel, and do so outside of the paint event? As opposed to painting directly onto the widget, which I think you should do only in onpaint?

    The more I think about it, the more I think there's some race condition, and you may be right on target with the resize. The sequence of events is like this:

    - Widgets previously displaying music score deleted, with the layout containing
    - New copies of them created (including a layout) with new sizes
    - Overlay created as child of a containing widget (that is not being deleted or resized)
    - Return to processing

    So the score gets resized, worse recreated in new containers, in the same consecutive code that creates the overlay.

    My GUESS Is that there is some race condition here, which is picking up the old QLabel sizes, or partially created, and blending those into the overlay for the translucent effect, but the actual size changes while it being displayed, throwing off the rendering. That would account for a delay fixing it, as by then the geometry has stabilized. So I do not think I'm calculating geometry wrongly, but rather that I am not forcing the sequence in some fashion I should be. I have tried update() and show() statements fore the overlay to no effect, though.

    PS. The reason I delete the underlying widgets and recreate is because in this transition the number across and down can also change; I probably should not delete them unless it does change, but if it did change I still have the problem so that is not a "fix". Nor in my mind is a clock time delay since that is an opportunity to be wrong less frequently as opposed to right.

  6. #6
    Join Date
    Jan 2008
    Location
    Alameda, CA, USA
    Posts
    4,491
    Thanks
    252
    Thanked 717 Times in 707 Posts
    Qt products
    Qt5
    Platforms
    Windows Android

    Default Re: Pixmap in translucent QLabel overlay, distorts screen

    Can you (or someone) answer one question from above -- is it indeed OK to paint into a QPixmap that is then "setpixmap()" into a QLabel, and do so outside of the paint event? As opposed to painting directly onto the widget, which I think you should do only in onpaint?
    Yes, this is completely OK. Painting into QWidget is restricted to paint events, but not pixmaps.

    But I'm not using translucent either, which I think is a key here.
    The only effect that translucency could possibly have is to cause a repaint of the widget underneath the overlay. Otherwise, I think you are barking up the wrong tree. Of course, if you try to test this by making your overlay opaque, you can't see the effect on the widget underneath because it will be completely obscured. However, as I suggested before, you can monitor the paint events on the QLabel using an event filter and determine under what circumstances the label is repainted (and the geometry it is painting into).

    Widgets previously displaying music score deleted, with the layout containing
    Why? There is normally no need to dynamically delete and re-create widgets in an otherwise static GUI. You should be simply replacing the content of the widgets, not the widgets themselves. Even if the number of things you display in a layout changes, you could use a stacked widget and simply flip which page is visible, depending on the configuration of your score. You could keep track of which configurations you have already created, and only create a new one on the fly if what you need is not already made. Otherwise, you pull an existing configuration, change the content, and make it the visible widget in the stack.

    My GUESS Is that there is some race condition here
    Not unless you are using threads. All GUI processing, whether yours or internally triggered by changes you make, occurs in the same thread and gets processed by the GUI thread's event loop. So anything you do or cause to occur will be processed in sequence. Qt will prune the event loop to remove unnecessary paint events, but it still ends up sequential.
    <=== The Great Pumpkin says ===>
    Please use CODE tags when posting source code so it is more readable. Click "Go Advanced" and then the "#" icon to insert the tags. Paste your code between them.

  7. #7
    Join Date
    Nov 2016
    Location
    Florida, US
    Posts
    26
    Thanks
    7
    Qt products
    Qt5
    Platforms
    Unix/X11

    Default Re: Pixmap in translucent QLabel overlay, distorts screen

    Thank you for the feedback, that will help. I am still working on another aspect (and learning more as I go) and have not come back to debugging that area.

    The reason for deleting and recreating is a change in number of widgets, e.g. displays 1 up, 2 up, 3 up, 4 x 2 up, etc. I have to resize them and replace their pixmaps when the count changes, and I assumed just deleting and recreating was simpler and maybe faster - but maybe not. Creating the max and hiding the ones not used is what you are suggesting?

    One thing I've been working on is changing the message output so I can get time to execute for every step. This taught me some of the hooks to get the other events instrumented as you suggest -- I'm certainly not ignoring that, just trying to get another whole section solid before I distract myself moving back to this.

    Thank you again for hanging in there. I'm learning a lot as I go, and maybe when I come back to the overlay I'll just see the problem.

    Threads: Not yet, though I plan to use them to render the pages (not widgets though) in background. Good to know the main display handler is all one thread.

  8. #8
    Join Date
    Jan 2008
    Location
    Alameda, CA, USA
    Posts
    4,491
    Thanks
    252
    Thanked 717 Times in 707 Posts
    Qt products
    Qt5
    Platforms
    Windows Android

    Default Re: Pixmap in translucent QLabel overlay, distorts screen

    Creating the max and hiding the ones not used is what you are suggesting?
    Yes. Look at QStackedWidget (which is built using QStackedLayout as a basis). Each of your display pages (1-up, 2-up, etc.) could be added as one page in the stack, and you simply call QStackedWidget::setCurrentIndex() to display the appropriate page. You wouldn't necessarily need a unique QWidget-based class for each page; you could add an argument to the "page" widget constructor to specify the page type, and build the appropriate configuration at that point.

    Another reason not to create and destroy lots of widgets on the fly is that you will start fragmenting memory (especially on Windows) because you'll likely never be able to fully reuse a piece of the heap that was used and then freed up. Windows will only compact adjacent free areas; it won't move in-use sections around.

    Threads: Not yet, though I plan to use them to render the pages
    I would consider threads only as a last resort, and only if the page rendering poses a significant overhead. If your page turns need to be instantaneous, then rendering the next page in advance could be an improvement, but doesn't need to be done in a thread. After all, you have all that time where the musician is playing what's on the current page; do it while that is going on.

    BTW, all painting to the GUI -must- be done in the main (GUI) thread. You cannot paint into a QWidget from a different thread.
    <=== The Great Pumpkin says ===>
    Please use CODE tags when posting source code so it is more readable. Click "Go Advanced" and then the "#" icon to insert the tags. Paste your code between them.

  9. #9
    Join Date
    Nov 2016
    Location
    Florida, US
    Posts
    26
    Thanks
    7
    Qt products
    Qt5
    Platforms
    Unix/X11

    Default Re: Pixmap in translucent QLabel overlay, distorts screen

    Quote Originally Posted by d_stranz View Post
    I would consider threads only as a last resort, and only if the page rendering poses a significant overhead. If your page turns need to be instantaneous, then rendering the next page in advance could be an improvement, but doesn't need to be done in a thread. After all, you have all that time where the musician is playing what's on the current page; do it while that is going on.

    BTW, all painting to the GUI -must- be done in the main (GUI) thread. You cannot paint into a QWidget from a different thread.
    To the last, I was only going to render to a QImage which is what the poppler-qt provides.

    But to the former -- OK, I give -- how do I relinquish control (so the person playing can touch a button) and also keep going and rendering pages. Won't any code I am running doing the render (in the main thread) block reaction to (say) touching the screen?

    The timing I am seeing running on a very fast desktop shows about 150-200ms to render each page to a QImage. This will be moving to a Raspberry Pi, so I'm expecting to see that up around a full second, which will be too slow, which is the reason for pre-rendering (but doesn't require multi-threading). The reason I was leaning toward multi-threading is that it APPEARS that the rendering itself is single threaded, and so even on the wimpy Pi I could render the first 2 (normal display) pages in parallel to get the initial display up twice as fast. But it's modular and the cache management (including any threading) was going to be one of the last things I tackled, after I had everything else working. So a better main-thread alternative would be nice, but I think I'm going to need the parallelism.

    I wanted to use the faster MuPDF but it currently won't link properly from the distros, and if I compile myself it crashes QT (and/or GTK+) due, I think, to replacing memory allocation routines (let's not pollute this thread, if interested I have an unanswered question here if anyone wants to comment, but it's long and complicated). poppler is working perfectly, just kind of slow.

  10. #10
    Join Date
    Nov 2016
    Location
    Florida, US
    Posts
    26
    Thanks
    7
    Qt products
    Qt5
    Platforms
    Unix/X11

    Default Re: Pixmap in translucent QLabel overlay, distorts screen

    Well.... #@$)(*)*$*$*# ....

    I went back to this and found it no longer failed the same way. It worked but was opaque. After some experimentation I found I needed to setAttribute(Qt::WATranslucentBackground). I never had that before (I had never seen it before, I stumbled across it).

    Now it works beautifully and as expected, even when I added animation (though it was a little jerky but that may be Xming on Windows).

    I spent about an hour trying to recreate the failure I had before without success. I had made a ton of (I thought) unrelated changes in other code, and apparently something else fixed this overlay (which class had not been touched), at least the cross-wise static-y aspect.

    I unfortunately was not saving backups as I wrote the code (shame on me -- it was on a VM so wasn't part of the normal backup), and don't have a version that fails, and cannot seem to create one, as I really wish I understood what I did wrong. As best I can tell I did not change sizing, though I did clean up real/int conversion in a few places that might have thown off something -- but on the other hand, none of that code ran between drawing the underlying thing, and the overlaying widget.

    thank you very much for trying to help, d_stranz, I wish I had a more definitive answer.

  11. #11
    Join Date
    Jan 2006
    Location
    Graz, Austria
    Posts
    8,419
    Thanks
    37
    Thanked 1,545 Times in 1,495 Posts
    Qt products
    Qt3 Qt4 Qt5
    Platforms
    Unix/X11 Windows

    Default Re: Pixmap in translucent QLabel overlay, distorts screen

    Quote Originally Posted by Linwood View Post
    I unfortunately was not saving backups as I wrote the code (shame on me -- it was on a VM so wasn't part of the normal backup)
    Off topic but that's why git is such a tremendously nice tool even for just local usag

    Cheers,
    _

  12. #12
    Join Date
    Nov 2016
    Location
    Florida, US
    Posts
    26
    Thanks
    7
    Qt products
    Qt5
    Platforms
    Unix/X11

    Default Re: Pixmap in translucent QLabel overlay, distorts screen

    It's on the list to learn. Sometimes the list should be in a different order.

  13. #13
    Join Date
    Jan 2008
    Location
    Alameda, CA, USA
    Posts
    4,491
    Thanks
    252
    Thanked 717 Times in 707 Posts
    Qt products
    Qt5
    Platforms
    Windows Android

    Default Re: Pixmap in translucent QLabel overlay, distorts screen

    The gods of code sometimes work in very mysterious ways. It isn't the first time something that didn't work suddenly started working (or more often, the other way around), and "I didn't touch anything in that module!"

    Onward and upward.

    As for your rendering, I am hard pressed to believe that you would have trouble rendering the next page of a score while the current one is being viewed, but maybe this is a Prokofiev or Liszt piano concerto or something with more ink than white space on the page. I don't know if you are rendering from a source like MusicXML or MIDI, but presumably you can process these in a piecewise fashion? If so, you can run your rendering code and at each stage, break out to call QCoreApplication::processEvents().


    There's a good article by Wysota here.
    <=== The Great Pumpkin says ===>
    Please use CODE tags when posting source code so it is more readable. Click "Go Advanced" and then the "#" icon to insert the tags. Paste your code between them.

  14. #14
    Join Date
    Nov 2016
    Location
    Florida, US
    Posts
    26
    Thanks
    7
    Qt products
    Qt5
    Platforms
    Unix/X11

    Default Re: Pixmap in translucent QLabel overlay, distorts screen

    Oh, I changed LOTS of things. It's no mystery that something fixed it, I just don't know what.

    As to rendering aspect -- the normal playing aspect is fine. There's nearly infinite amount of time (relative to what's needed) between one page and the next while playing forward.

    However, there are other modes:

    1) Select a song, and want to start -- it's annoying (if not significant) to wait 4 seconds before the first two pages appear, but...

    2) I have a mode with 4 x 2 pages shown for browsing, e.g. looking for a specific spot in a large score. Those render a bit faster, but not fast enough - now I have maybe 10-12 seconds to render all 8 pages to get the first display or the next if I immediately hit "next".

    The second is far more serious, and is probably the main reason I need to cache and have multi-threading, so when I first load up, I can pretty quickly get well ahead of the pages that might be displayed if they go into that mode.

    I think the longest song I have is 12 pages, but in reading about other people who have done this, they describe music 300 pages long. I don't know that anyone other than me will ever use this, but I ought to try to make it useful if so in those cases, so I need a sliding window of cached pages that can go pretty quickly.

    There's also:

    3) going back. This is a bit easier if I have a cache as it should already be there but is a good example of where you don't have a lot of time. Music sometimes repeats, and the repeat-from may be anywhere from a few bars back from your current spot on the same page, to several pages back. You want to get back to that page quickly when you hit the repeat point, as there may be no available transition (transitions are a whole different matter because you want the new page displayed before you really quite finish the current -- going forward that's easy, not so easy going back).

    Handling those transitions, like putting up half a page at times, is what I was working on that "fixed" the overlay I had.

    Now I'm working on cache management and multi-threading, so who knows what I'll break ... or fix. I think I've conceptually got what I need, and good isolation, but haven't gotten enough written to even hit Build yet.

  15. #15
    Join Date
    Jan 2008
    Location
    Alameda, CA, USA
    Posts
    4,491
    Thanks
    252
    Thanked 717 Times in 707 Posts
    Qt products
    Qt5
    Platforms
    Windows Android

    Default Re: Pixmap in translucent QLabel overlay, distorts screen

    Sounds like rendering pages into a cache using rendering thread(s) might be the best option. You might also consider non-real-time rendering - a separate program or mode to render a score into a permanent cache, from which you can then pull page images at play time.

    I've seen several classical and jazz pianists (Keith Jarrett for one) playing from a tablet instead of a paper score, so it's a growing trend. A 300 page score is something the conductor might use for a full-length symphony or opera, but I think I'd have a hard time (as a conductor) working from a tablet. It would be too small to see.
    <=== The Great Pumpkin says ===>
    Please use CODE tags when posting source code so it is more readable. Click "Go Advanced" and then the "#" icon to insert the tags. Paste your code between them.

  16. #16
    Join Date
    Nov 2016
    Location
    Florida, US
    Posts
    26
    Thanks
    7
    Qt products
    Qt5
    Platforms
    Unix/X11

    Default Re: Pixmap in translucent QLabel overlay, distorts screen

    My own implementation is with a 21" flat screen monitor that sits on a piano. That makes most music displayed approximately life sized two up, like a book, so it feels rather nice. Mostly I did this for my wife who is learning, and has these big massive books that will not stay open, plus I find it very nice.

    I'm tying it to Calibre on my desktop (which is always up), and using Calibre as a library of music. That gives me some pre-built advantages, plus I already use it for eBooks. My goal was to keep nothing permanently on the Pi, so if I (for example) mark up a page with annotations, I planned to shove it somehow back in Calibre as an annotated version. In principle this is then usable on any device with network connectivity to a "server".

    If I can ever learn enough about Qt to actually FINISH it. The threading version is mostly working now, though I have some issues with cleaning up QImage references passed between. Back to work...

Similar Threads

  1. Overlay 2 images in QLabel
    By 2lights in forum Qt Programming
    Replies: 1
    Last Post: 6th August 2013, 21:36
  2. Painting an overlay on a QLabel->QImage
    By papillon in forum Qt Programming
    Replies: 7
    Last Post: 10th July 2012, 09:28
  3. Pixmap updating QLabel
    By Matt in forum Newbie
    Replies: 11
    Last Post: 17th August 2010, 21:11
  4. empty pixmap as a QLabel
    By tommy in forum Qt Programming
    Replies: 16
    Last Post: 11th December 2007, 21:15
  5. Pixmap Overlay
    By ToddAtWSU in forum Qt Programming
    Replies: 5
    Last Post: 22nd June 2006, 20:19

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Digia, Qt and their respective logos are trademarks of Digia Plc in Finland and/or other countries worldwide.