Rework painting to be based on Region union/subtract operations

RESOLVED FIXED

Status

RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: taras.mozilla, Assigned: taras.mozilla)

Tracking

(Blocks: 1 bug)

Trunk
x86
Linux
Dependency tree / graph

Details

Attachments

(1 attachment, 6 obsolete attachments)

(Assignee)

Description

10 years ago
I'm thinking of having page-sized Region where paints unioned up, then as the user pans we intersect to the current viewport to get rid of any rectangles that didn't get painted yet.

The viewingRect will be painted immediately and calculated via cloning the page region + intersecting it with viewingrect(ie to avoid destroying the pageRegion).

The offscreen stuff would be painted via a timer and flushed before pan.

This gets rid of the current queue, and hopefully will get rid of the _clippedDrawingMode as all drawing will be clipped
(Assignee)

Comment 1

10 years ago
Created attachment 362963 [details] [diff] [review]
mostly working

This patch dirties rectanges in the region(intersected with pageBounds). It's pretty much exactly the same functionality as achieved with the queue, except that panning does not cause all optimizations to cease, instead it just pauses them atm.

I also made drawing blank canvas space in viewportHandler go through _redrawRect. This has the benefit that during panning on pageload, the visible area is painted first. 

Eventually I would like to prioritize all paints(ie after page loads too) so visible things get drawn and rest is queued on an interval. This will help on pages with animated gifs, with panning past viewportbounds and zooming responsiveness.


Unfortunately there are drawing bugs in this that happen during extreme amounts of panning on slow loading pages(any large foreign site will do, i use pravda.ru).. To make them easier to reproduce comment out "this._isPanning = true", seems that delaying paints is screwing something up, but I can't find which offset is being screwed up.

Gavin, stuart and maybe others, could you take a look at this to figure this out? I can't reproduce the offset corruption on the device while panning.

Also since this takes out a lot of the big redraws it makes bug 477519 really obvious on the desktop. It shows up while panning and drawing in missing pieces(ie panning while zoomed in) and overall in the page. No such drawWindow corruption happens on target.
(Assignee)

Comment 2

10 years ago
spoke too soon, drawing in missing areas also happens on target if pan happens in both vertical and horizontal directions, single axis pans seem to work ok.
(Assignee)

Comment 3

10 years ago
(In reply to comment #2)
> spoke too soon, drawing in missing areas also happens on target if pan happens
> in both vertical and horizontal directions, single axis pans seem to work ok.

I meant that ends up with things not lining up correctly
(Assignee)

Comment 4

10 years ago
Created attachment 362997 [details] [diff] [review]
minial change to not overlap the blit
(Assignee)

Comment 5

10 years ago
Created attachment 363016 [details] [diff] [review]
fixes scroll offset math

Either the blit or the offsets have to be decimals or things don't line up. Stuart says the blit needs to be in whole pixels.

This might also be the issue behind 477519
Attachment #362997 - Attachment is obsolete: true
Attachment #363016 - Flags: review?(pavlov)
(Assignee)

Comment 6

10 years ago
Forgot to mention, 363016 also switches to iterating over rects to finish redrawing post-blit, which should be a speedup. I'd like to commit this before moving on to more painful bits in the first patch.
(Assignee)

Comment 7

10 years ago
Created attachment 363166 [details] [diff] [review]
apply this after scroll offset patch

This patch needs some more debugging for some reason when I uncomment rect.intersect things go to hell once the page loads and the area under the viewport is not painted.
Attachment #362963 - Attachment is obsolete: true
(Assignee)

Comment 8

10 years ago
Created attachment 363199 [details] [diff] [review]
need help with this

So two bugs here: when loading slashdot over network only the visibleBounds are drawn. From the debug messages looks like the rest of the canvas should get drawn, but it doesn't for some reason.

Another more facinating bug is that I follow every drawWindow call with a translucent fillRect in same coordinates, but while panning or zooming the translucent red part is not drawn on parts of the page
Attachment #363166 - Attachment is obsolete: true
(Assignee)

Comment 9

10 years ago
Created attachment 363200 [details] [diff] [review]
need help with this(fixed typo)
Attachment #363199 - Attachment is obsolete: true
(Assignee)

Updated

10 years ago
Depends on: 363232
(Assignee)

Updated

10 years ago
Depends on: 478092
No longer depends on: 363232
(Assignee)

Comment 10

10 years ago
Created attachment 363427 [details] [diff] [review]
working patch
Attachment #363016 - Attachment is obsolete: true
Attachment #363200 - Attachment is obsolete: true
Attachment #363427 - Flags: review?(pavlov)
Attachment #363016 - Flags: review?(pavlov)

Comment 11

10 years ago
Comment on attachment 363427 [details] [diff] [review]
working patch

looks good -- good job
Attachment #363427 - Flags: review?(pavlov) → review+
(Assignee)

Comment 12

10 years ago
pushed http://hg.mozilla.org/mobile-browser/rev/70d5ea2253a5
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Assignee: nobody → tglek
You need to log in before you can comment on or make changes to this bug.