Still a problem.

Created attachment 20129 [details]
Large selection in editor

This is a first patch to handle large selection with auto scrolling in editor.
It not perfect because sometimes the selected area rectangle is not properlly
clean before scrolling when you mouse a selction corner outside of the visible
image canvas.

I have polished, fixed, and commented the code in canvas.cpp. More
investiguatoins are require.

Marcel, 

i would have your viewpoint about this patch. 

I have work hard to understand how canvas selection working exactly. All work fine excepted the clean-up of selection rubber when auto-scrolling is used to pan canvas.

Can you take a look please... Thanks in advance...

Gilles

The patch works nicely here. Only once I had a small part of the line from the rubber band not cleaned. I tried hard to reproduce the problem, without success.

Luka,

Can you test the patch on your computer and give me a report ?

Gilles

Nice improvement - works for me.

SVN commit 648898 by cgilles:

digiKam from trunk : Image editor selection improvement : canvas is able to select a region largest than the current visible image.
BUG: 116148


 M  +18 -8     canvas.cpp  


--- trunk/extragear/graphics/digikam/utilities/imageeditor/canvas/canvas.cpp #648897:648898
@@ -466,8 +466,8 @@
                QMIN(er.height() + 2, contentsRect().height()));
     
     paintViewport(er, (d->zoom <= 1.0) ? true : false);
-    if (d->zoom > 1.0)
-        d->paintTimer->start(100, true);
+/*    if (d->zoom > 1.0)
+        d->paintTimer->start(100, true);*/
 }
 
 void Canvas::slotPaintSmooth()
@@ -537,7 +537,7 @@
                     sw = (int)floor(d->tileSize / d->zoom);
                     sh = (int)floor(d->tileSize / d->zoom);
 
-                    if (d->rubber && d->pressedMoved)
+                    if (d->rubber && d->pressedMoved && !d->pressedMoving)
                     {
                         QRect rr(d->rubber->normalize());
                         rr = QRect(d->rubber->normalize());
@@ -655,8 +655,12 @@
             }
         
             viewport()->setMouseTracking(false);
+            d->pressedMoved  = false;
+            d->pressedMoving = true;
 
-            d->pressedMoving = true;
+            d->tileCache.clear();
+            viewport()->repaint(false);
+
             return;
         }
     }
@@ -716,22 +720,28 @@
               d->lbActive || d->rbActive))
             return;
 
-        drawRubber();
+        // Clear old rubber.
+        if (d->pressedMoved)
+            drawRubber();
 
+        // Move content if necessary.
+        blockSignals(true);
+        ensureVisible(e->x(), e->y(), 10, 10);
+        blockSignals(false);
+
+        // draw the new rubber position.
         int r, b;
         r = (e->x() > d->pixmapRect.left()) ? e->x() : d->pixmapRect.left();
         r = (r < d->pixmapRect.right())     ? r      : d->pixmapRect.right();
         b = (e->y() > d->pixmapRect.top())  ? e->y() : d->pixmapRect.top();
         b = (b < d->pixmapRect.bottom())    ? b      : d->pixmapRect.bottom();
-
         d->rubber->setRight(r);
         d->rubber->setBottom(b);
+        drawRubber();
 
         d->pressedMoved  = true;
         d->pressedMoving = true;
 
-        drawRubber();
-
         // To refresh editor status bar with current selection.
         emit signalSelectionChanged(calcSeletedArea());
     }

Created attachment 20145 [details]
rubber redraw problem example

Marcel, Luka,

Look the screenshot witch reproduce the problem. It easy to do : open a large
picture, zoom to 300, and start to select an area. Now move the selection very
quickcly outside the current visible canvas area. The scrollview will move the
content automaticly, but sometime, the rubber is not cleanned, accordinly with
the mouse mouvements. 

I suspect a problem about to dispatch messages to force the rubber to be
cleaned. Note the rubber is draw/cleaned using the same method drawRubber()
witch use a NOT raster operator.

Gilles

The problem is something like this:
When autoscrolling to a new area, this area is not yet drawn, an update is scheduled by the ensureVisible(). The rubber is drawn immediately.
Then in the drawContents method, the new area is drawn, and the rubberband is removed.
In the next mouseMove event, drawRubber is called to remove the rubber in the old position, but the rubber is already removed by repainting, so it is not removed, but actually drawn at the old position in the first drawRubber call.

I tried to solve it by calling drawRubber before and after painting in drawContents, if (d->rubber && d->pressedMoved && d->pressedMoving && d->rubber->intersects(pr)), but this solves it only when scrolling downwards...strange.

Why is this marked as solved in view of #8 and #9?