QLabel vs QGraphicsView performance - performance

I am learning QT and I am puzzled by the difference in performance of QLabel and QGraphics view while panning.
I read a huge 36Mpixels (D800) jpeg file into either QLabel or QGraphics objects and try to drag the full scale image with QLabel/Graphics. Surprisingly, the QLabel provides really smooth movement while QGRaphicsView panning is jerky.
The simplified QGraphicsView code is:
QApplication::setGraphicsSystem("raster");
...
QGraphicsView view();
view.setDragMode(QGraphicsView::ScrollHandDrag);
view.setHorizontalScrollBarPolicy(Qt::ScrollBarAlwaysOff);
view.setVerticalScrollBarPolicy(Qt::ScrollBarAlwaysOff);
view.setFrameStyle(QFrame::NoFrame);
view.showFullScreen();
QGraphicsPixmapItem *pmItem = new QGraphicsPixmapItem(pixMap);
scene.addItem(pmItem); // only one item in the scene
//view.setRenderHints(QPainter::Antialiasing | QPainter::SmoothPixmapTransform); // no difference
view.show();
The simplified QLabel based code is:
void MyQLabel::mouseMoveEvent(QMouseEvent *event){
if(_leftButtonPressed) {
// calculate new {_x, _y} position
repaint();
}
} else super::mouseMoveEvent(event);
}
void MyQLabel::paintEvent(QPaintEvent *aEvent){
QPainter paint(this);
paint.drawPixmap(_x, _y, pixMap);
}
... // Somewhere in the code:
MyQLabel _myLabel(NULL);
_myLabel.showFullScreen();
_myLabel.show();
It feels like QGraphicsView is skipping the over some positions (with fast dragging), while QLabel paints at all intermediate images.
What do I miss?
Thank you
Alex

Likely, the QGraphicsView calls update() when a scroll change is detected.
While your label calls repaint().
The difference is that update() schedules a call to repaint() and multiple rapid calls to update() may call repaint() a single time.
When fast dragging, you might register multiple mouse events in a short time frame. The QGraphicsView will handle all of them and for each of them call update() and only once they are all processed repaint() is actually called.
Your label will force a repaint() for each mouse event.
Your label may be smoother than the graphics view, but it will consume more resources, and on limited hardware the label will lag behind the mouse cursor as the hardware is trying to process all the repaints.

Related

Flutter - more efficient pan and zoom for CustomPaint

I'm rendering a collection of grids of tiles, where each tile is pulled from an image. To render this, I'm rendering everything inside my own implementation of CustomPainter (because the grids can get pretty large). To support pan and zoom functionality, I opted to perform the offsetting and scaling as part of canvas painting.
Here is a portion of my custom painting implementation.
#override
void paint(Canvas canvas, Size size) {
// With the new canvas size, we may have new constraints on min/max offset/scale.
zoom.adjust(
containerSize: size,
contentSize: Size(
(cellWidth * columnCount).toDouble(),
(cellHeight * rowCount).toDouble(),
),
);
canvas.save();
canvas.translate(zoom.offset.dx, zoom.offset.dy);
canvas.scale(zoom.scale);
// Now, draw the background image and grids.
While this is functional, performance can start to breakdown after enough cells are rendered (for example, a grid of 100x100 causes some lag on each GestureDetector callback that updates the zoom values). And, because the offsetting and scaling is done in the CustomPaint, I basically can't return false for bool shouldRepaint(MyPainter old) because it needs to repaint to render its new offset and scale.
So, my question is: What is a more performant way of approaching this problem?
I've tried one other approach:
var separateRenderTree = RepaintBoundary(
child: OverflowBox(
child: CustomPaint(
painter: MyPainter(),
),
),
);
return Transform(
transform: Matrix4.translationValues(_zoom.offset.dx, _zoom.offset.dy, 0)..scale(_zoom.scale),
child: separateRenderTree,
);
This also works, but can also get laggy when scaling (translating is buttery smooth).
So, again, what is the right approach to this problem?
Thank you.
Here's where I ended up.
I size my custom painter to be as large as it needs, and then I position it inside a Transform widget (that is top-left aligned with an offset of zero).
On top of this widget I overlay an invisible widget that manages touch inputs. Using a GestureDetector, it will respond to events and notify the Transform widget to update.
With the pan/zoom officially moved out of the painter, I then implemented the "shouldRepaint" function to be more strict.
This has allowed me to render very, very large grids at good-enough speeds.

p5js only drawing what's needed

I'm looking for a way to limit what gets done in the draw loop.
I have a system where when I click, it add's a rect.
This rect then starts spawning circles that move.
since the rect does not change location, it isn't ideal to redraw it in every frame.
Is there a way to put the rects on a different layer of sorts, or is there another mechanism that I can use to limit the rect-drawing without impeding the circle-drawing?
I've tried with createGraphic to make a background with the rects, but I can't make the 'foreground' where the circles reside to be transparant.
Curious about this I tried myself. My idea was simply grabbing the canvas and interacting with it regardless of p5.js.
My result was that the draw... in this case ctx.fillRect did not render on screen.
However the fillStyle was changed.
Canvas is surprisingly efficient as well as WebGL and can handle the performance usually... unless you are rendering hundreds(mobile) to thousands(laptop/desktop) of objects.
I would have liked to have a better outcome but I think it was worthwhile posting what I had tried and my outcome nonetheless.
//P5 Setup
function setup(){
createCanvas(1500, 750);
background('rgba(0, 0, 0, 0.3)');
stroke(255);
fill(255)
doNonP5Drawing();
}
//Render
function draw(){
background(0);
frame();
}
function doNonP5Drawing(){
let canvas = document.querySelector('canvas'),
ctx = canvas.getContext('2d');
ctx.fillStyle="red";
ctx.fillRect(canvas.innerWidth/2 - 100,canvas.innerHeight/2 - 100,200,200);
}

How can I clear the canvas using one click in processing?

I was trying to make a very simple game but I'm having trouble with mouse events. I want to only click once and the whole canvas will be cleared but what happen is it keeps on coming back to its original canvas if I'm not clicking anymore.
if((mouseX >= 100) && (mouseX <= 235) &&
(mouseY >= 490) && (mouseY <= 540) &&
(mousePressed))
{
clear ();
slide1 ();
}
This is the second tab:
void slide1()
{
clear ();
background (30);`enter code here`
slide1 = loadImage ("slide1.jpg");
image (slide1,100,0,400,300);
}
Without seeing a complete, working example, it is difficult to tell for certain. However, it seems likely that you have confused clear() and background(). The easiest way to wipe the screen is by calling background() -- for example at the beginning of every draw() frame.
From the Processing reference:
clear(): "Clears the pixels within a buffer. This function only works on PGraphics objects"
background(): "This function is typically used within draw() to clear the display window at the beginning of each frame, but it can be used inside setup() to set the background on the first frame of animation or if the backgound need only be set once."
e.g. (based on your code):
PImage slide1;
void setup(){
size(512,512);
slide1 = loadImage ("https://processing.org/img/processing3-logo.png");
}
void draw(){
background (30); // clear screen every frame
if(mousePressed) { // show image whenever mouse is down
image (slide1,0,0);
}
}
This always clears the canvas.
Alternately, if you only want to wipe the canvas on a click, don't call background each draw -- instead, call background only on mousePressed. However, in your case (showing an image) it looks like you might also want to wipe again on mouseReleased (so that the image disappears). You may wish to use the built-in mousePressed() and mouseReleased() Processing functions for this and call background in each one.
I don't think this is what you actually want, but: the actual answer to the title question ("How can I clear the canvas using one click in processing?") is:
void draw(){
line(mouseX,mouseY,pmouseX,pmouseY);
}
void mouseClicked(){
background(192);
}

Scrollable drawing in Gtk::Layout

I'd like to use custom drawing within a Gtk::Layout. That is, I'm using the C++ bindings for Gtk3 (GTKmm 3.14.0), and I have embedded widgets placed on the "canvas", on top of my custom drawing. Basically this works just fine.
Now the problem is related to scrolling. Gtk::Layout can be placed into a Gtk::ScrolledWindow, and when the scrollable area is set to something larger than the visible allocation, scrollbars will show up. Unfortunately, those scrollbars influence only the placement of the embedded widgets, while my custom drawing remains at a fixed position within the window.
This means, both the Gtk::Allocation and the cairo context seem to be related to precisely the visible area, not to the extended virtual "canvas". I could work around that problem by accessing the adjustments from the scrollbars and then translate the cairo context accordingly...
My question is:
is this the proper way to handle such a scrollable drawing?
or is there some way to let the framework do this work for me?
Judging from the source code of gtk+3.0-3.14.5 (which is in Debian/Stable), the Gtk::Layout does nothing to adjust the drawing context. It just invokes the inherited draw() function from GtkWidget. On the other hand, Gtk::Layout is a full-blown container (it inherits from Gtk::Container), and it is scrollable, which together means that it handles gtk_layout_size_allocate() by passing a suitable allocation (screen area) to each of the embedded child widgets -- and in this respect it does handle the moving and clipping related to scrolling the virtual canvas (calls gdk_window_move_resize()).
Thus, if we want to combine the embedded child widgets with custom drawing, we need to bridge this discrepancy manually. This is quite easy actually: all we need to do is to look into the Gtk::Adjusments corresponding to the scrollbars. Because the value of these adjusments is precisely the upper left corner of the visible viewport. Now, if we want our custom drawing to use absolute canvas coordinates, we just have to translate() the given Cairo context. Beware: it is important to save() the state and to restore() it to pristine state when done, otherwise those translations will accumulate.
Here is some example code to demonstrate this custom drawing
we derive a custom container class called Canvas from Gtk::Layout
we override the on_draw() handler, because only there all size allocation to embedded child widgets have been processed
Layering: child widgets are always drawn in the order they have been added to the Gtk::Layout container. Any custom drawing done before invoking the inherited on_draw() function will be below those widgets; any drawing done afterwards will happen on top of them.
if necessary, we can use the foreach(callback) mechanism to visit all child widgets to find out their current position and extension
void
Canvas::determineExtension()
{
if (not recalcExtension_) return;
uint extH=20, extV=20;
Gtk::Container::ForeachSlot callback
= [&](Gtk::Widget& chld)
{
auto alloc = chld.get_allocation();
uint x = alloc.get_x();
uint y = alloc.get_y();
x += alloc.get_width();
y += alloc.get_height();
extH = max (extH, x);
extV = max (extV, y);
};
foreach(callback);
recalcExtension_ = false;
set_size (extH, extV); // define extension of the virtual canvas
}
bool
Canvas::on_draw(Cairo::RefPtr<Cairo::Context> const& cox)
{
if (shallDraw_)
{
uint extH, extV;
determineExtension();
get_size (extH, extV);
auto adjH = get_hadjustment();
auto adjV = get_vadjustment();
double offH = adjH->get_value();
double offV = adjV->get_value();
cox->save();
cox->translate(-offH, -offV);
// draw red diagonal line
cox->set_source_rgb(0.8, 0.0, 0.0);
cox->set_line_width (10.0);
cox->move_to(0, 0);
cox->line_to(extH, extV);
cox->stroke();
cox->restore();
// cause child widgets to be redrawn
bool event_is_handled = Gtk::Layout::on_draw(cox);
// any drawing which follows happens on top of child widgets...
cox->save();
cox->translate(-offH, -offV);
cox->set_source_rgb(0.2, 0.4, 0.9);
cox->set_line_width (2.0);
cox->rectangle(0,0, extH, extV);
cox->stroke();
cox->restore();
return event_is_handled;
}
else
return Gtk::Layout::on_draw(cox);
}

Printing CALayers

I have a NSView which contains many CALayers. When a user is editing a document, these CALayers animate all edits. I am attempting to implement printing for my app, but I am having some problems printing these CALayers correctly.
Some CALayers bounds occupy the entire NSView, and do not need to be laid out, because their position never changes. However, I also have one CALayer which contains about 20 small CALayers. These CALayers animate their position changes during normal editing. However, when attempting to print the NSView, these small CALayers never get laid out correctly. I am wondering if there is something special I have to do to ensure that these layers are positioned correctly, and allow the NSView to be drawn/printed correctly.
Does anyone have experience printing a Core Animation backed NSView? Any suggestions are appreciated.
In order to work around layout issues, as well as the fact that using -renderInContext: to draw a layer hierarchy does not preserve vector elements, we subclassed CALayer in the Core Plot framework. The CPLayer subclass overrides the default -drawInContext: method to call our custom -renderAsVectorInContext: method (where we do all of our Core Graphics drawing for a layer). To generate a PDF context (or similar) for printing, we then call a custom method with the following code:
-(void)recursivelyRenderInContext:(CGContextRef)context
{
// render self
CGContextSaveGState(context);
[self applyTransform:self.transform toContext:context];
self.renderingRecursively = YES;
if ( !self.masksToBounds ) {
CGContextSaveGState(context);
}
[self renderAsVectorInContext:context];
if ( !self.masksToBounds ) {
CGContextRestoreGState(context);
}
self.renderingRecursively = NO;
// render sublayers
for ( CALayer *currentSublayer in self.sublayers ) {
CGContextSaveGState(context);
// Shift origin of context to match starting coordinate of sublayer
CGPoint currentSublayerFrameOrigin = currentSublayer.frame.origin;
CGRect currentSublayerBounds = currentSublayer.bounds;
CGContextTranslateCTM(context,
currentSublayerFrameOrigin.x - currentSublayerBounds.origin.x,
currentSublayerFrameOrigin.y - currentSublayerBounds.origin.y);
[self applyTransform:self.sublayerTransform toContext:context];
if ( [currentSublayer isKindOfClass:[CPLayer class]] ) {
[(CPLayer *)currentSublayer recursivelyRenderInContext:context];
} else {
if ( self.masksToBounds ) {
CGContextClipToRect(context, currentSublayer.bounds);
}
[currentSublayer drawInContext:context];
}
CGContextRestoreGState(context);
}
CGContextRestoreGState(context);
}
This goes through and renders each layer onto a flat Core Graphics context, preserving position, rotation, and other transforms while rendering all elements as sharp vectors.
One other thing to watch out for when trying to render layers is that the state of your presentation layer hierarchy may not be the same as your internal layer hierarchy. You may have animations that have been applied to move your layers, but the layers' position properties may not have been changed to match. In that case, you should make sure that you either animate the properties themselves, so that the values always stay in sync, or set the values in your layer once the animations have completed.
Last I looked into it, it was not possible to properly print CALayers. It seemed to me at the time that Core Animation was designed for screen only and not for print (which seems consistent with the fact that it was designed initially for iPhone).
I'd love to know I'm wrong.

Resources