Issue 120596 – When using scroll arrows w/high-resolution image/zoomed in, scroll arrows stick down indefinitely until the side of the document is reached

Issue 120596 - When using scroll arrows w/high-resolution image/zoomed in, scroll arrows stick down indefinitely until the side of the document is reached


Summary:	When using scroll arrows w/high-resolution image/zoomed in, scroll arrows sti...

Status:	RESOLVED FIXED

Product:	Draw
Classification:	Application
Component:	ui
Version:	3.4.0
Hardware:	PC Windows XP

Importance:	P3 Major (vote)
Target Milestone:	4.0.0
Assigned To:	Armin Le Grand
QA Contact:

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2012-08-16 17:00 UTC by Lance Gropper
Modified:	2013-07-12 16:20 UTC (History)
CC List:	1 user (show)

See Also:
Issue Type:	DEFECT
Latest Confirmation in:	---
Developer Difficulty:	---

Attachments
Document demonstrating problem. (15.34 KB, application/vnd.oasis.opendocument.graphics) 2012-08-20 20:22 UTC, Lance Gropper	no flags	Details
Video showing problem (451.62 KB, video/3gpp) 2012-08-23 17:28 UTC, Lance Gropper	no flags	Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.

Description Lance Gropper 2012-08-16 17:00:38 UTC

I created a new document in draw, and imported one 5 Megapixel image - it was cropped to about 1/10th it's size and resized about another 10% smaller. Next to it, I put a bitmap which was cut and pasted from Adobe Acrobat. The image was also cropped to about 1/10th it's size and resized to be about the same size as the first image. I created several shapes (mainly rectangles) next to this - approximately 15 of them, with gradient fills. The images/rectangles are very thin (i.e. document is 19"x8", and images/rectangles are about 1/2" wide each, placed side-by-side), so that if you zoomed in approximate 1000% on a 1920x1080 screen, the three fill the screen without being off the edge.

If you then click one of the arrows on the scroll bar - i.e. to scroll just a little in that direction, the arrow sticks down and keeps scrolling until the side of the document is hit. This makes it very difficult to get back, as if you then hit the arrow to go the other way, it scrolls non-stop until it hits that side.

System/graphics are a little better than average. This is a Lenovo Thinkpad T510 laptop, with a Core i5 dual-core 3.6GHz processor. Graphics are an nVidia Quadro NVS3100, running Windows XP/32. Problem also occurs on a different system, with a Phenom II X4 Quad-Core 2.5GHz, with nVidia GeForce GTX550.

Comment 1 Armin Le Grand 2012-08-20 10:43:21 UTC

ALG: Hi Lance, could you eventually provide a test file for this? Thanks in advance!

Comment 2 Lance Gropper 2012-08-20 20:22:29 UTC

Created attachment 79008 [details]
Document demonstrating problem.

Sample attached. It's extremely easy to reproduce: All I did for the example, is open a small window (I'm running Microsoft Windows XP), create a screenshot of that window, by pressing Alt-PrtSc. I started OpenOffice draw, pasted the screenshot stretched it larger, added one rectangle, then zoomed in all the way, and presto - won't stop scrolling in any direction once started.

Comment 3 Armin Le Grand 2012-08-21 11:07:40 UTC

ALG->Lance: Thanks, I'll have a look soon!

Comment 4 Armin Le Grand 2012-08-23 11:56:12 UTC

ALG: I see the following:
- Scrolling is *very* slow (need to check what is using so much time to draw a zoomed part of a bitmap)
- The scrollbar arrows have an 'auto-repeat'; klicking once and waiting that the scroll finishes works. When keeping the mpuse button pressed, multiple presses will be recorded and it may take a loooong time to finish scrolling (since each single step is slow), but it finishes.

Thus not a locking problem (not infinite), but a performance problem.

Comment 5 Armin Le Grand 2012-08-23 14:47:28 UTC

ALG: Ith has nothing to do with the graphic objects involved (when removing all, sitll slow scrolling), but with the grid you were choosing; it's simple too small distances. Switch it off or choose other step widths and all works well.
The grid point generation in the grid primitive decomposition is not optimal; currently all logical grid positions are tested for being visible. This is done since the grid primitive itself can be freely transformed (rotated, sheared, etc.) and thus does not have to be axis-aligned with the view (not yet used, but potentially possible).
Took a closer look and implementing a more performant method for creation...

Comment 6 Lance Gropper 2012-08-23 15:03:31 UTC

I found a really-bad work-around: If it starts to scroll, then you try to force-quit the application - i.e. by right-clicking it's entry on the start bar, then clicking close, it stops scrolling to show the popup asking whether to save, quit, or cancel. If you then cancel, the scrolling stops.

Comment 7 SVN Robot 2012-08-23 15:03:45 UTC

"alg" committed SVN revision 1376528 into trunk:
#120596# Optimized grid primitive, added some tooling to basegfx

Comment 8 Armin Le Grand 2012-08-23 15:06:05 UTC

ALG: Comitted, done.
@Lance: Crude workaround, but if it works... Probably works because the message queue containing all that mouseclicks (or mousedown) gets consumed. Well, thanks for supporting AOO and submitting this task! It will be in the next version (AOO3.5..?)

Comment 9 Lance Gropper 2012-08-23 15:12:08 UTC

But it wasn't mouse-clicks or hold down - one quick click starts it going.

Comment 10 Armin Le Grand 2012-08-23 15:34:54 UTC

ALG->Lance: Hmmm, could not reproduce that. Is it dependent of the graphic being there? Does it happen when you switch grid off?

Comment 11 Lance Gropper 2012-08-23 15:47:11 UTC

It occurs with or without the bitmap, but only occurs with the grid on. Also, if I set the grid to a lower density as you suggested, it does not occur, but I need the higher density to be able to work when zoomed in like that...

Comment 12 Armin Le Grand 2012-08-23 16:18:10 UTC

ALG->Lance: Fine, then it should be fixed with my changes. It will be as fast as without grid (nearly). If it's too slow, some autorepeat may start, because the mousebutton may be released, but for the app it is still pressed.

Comment 13 Lance Gropper 2012-08-23 16:40:34 UTC

I tried to upload a video of the problem, but it is 2.6MB, and the limit is apparently 1MB. The video clearly shows the mouse-press, I released immediately then moved it away from the arrow/button - I could have let the screen continue scrolling for about 3 minutes, but it goes for 45 seconds in the video...

Comment 14 Lance Gropper 2012-08-23 17:28:06 UTC

Created attachment 79102 [details]
Video showing problem

I had to have the resolution lowered to be able to transfer it, but you can still make it out...