622469 - Unnecessary copies in createPattern

Status: NEW

(Core :: Graphics: Canvas2D, defect)

Description

[Thomas Jones]

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0b9pre) Gecko/20101228 Firefox/4.0b9pre
Build Identifier: 


this seems to generate a temporary copy of the source:

// buffer is a canvas, but not the same one that cr is drawing to. 
// ie buffer != cr.canvas, they are the same width/height though
cr.save();
cr.fillStyle = cr.createPattern(buffer, "repeat-x");
cr.translate(-vpx, 0);
cr.fillRect(0, 0, w*2, h);
cr.restore();


The goal is to create a scrolling effect, so that I update a column of pixels in buffer, then later on draw with cr into a visible canvas such that the contents of buffer appear to scroll sideways.

If I try to do it with the above snippet it works for a second or so, then slows down.

Workaround is to do it this way:
cr.drawImage(buffer, -vpx-1, 0);
cr.drawImage(buffer, w-vpx-1, 0);

but I like the first way since it only involves one draw operation.

Reproducible: Always

Comment 1

[Ed Morley [:emorley]]

Can you attach as a html testcase please.

Also, related to bug 468358 at all?

Comment 2

[Thomas Jones]

I'm not sure if it's related to bug 468358 or not... could be, if the code doesn't look like it does in Comment 2 of that bug anymore... what happens in the y direction shouldn't matter (I could actually just use "repeat" and the final rendering shouldn't change)

I have a page I'm playing with, but it has a bunch of other stuff and it's spread out over a bunch of files, I'll make a test case soon though.

I only really notice a serious slowdown if firefox is otherwise using lots of memory (I have 100s of tabs open most of the time...) in a fresh profile it just causes a gc pause every few seconds.

Comment 3

[Thomas Jones]

Attachment: testcase

Adding test case, there's a checkbox, check it to make it switch to using the non-workaround version of the code. (it starts off using the version with the workaround)

Comment 4

[Ed Morley [:emorley]]

Thanks for the testcase.

Testcase WFM (no difference between ticked and not) with ~80 tabs open, 1.5GB working set using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20110102 Firefox/4.0b9pre ID:20110102030355

Does enabling/disabling hardware acceleration make any difference for you?

Does this still occur if you create a clean profile (with no addons), open a load of tabs to simulate a large session, then run the testcase htm?

Does this occur in 3.6.13?

Comment 5

[Thomas Jones]

Don't know about 3.6.13 (I don't have it installed, just betas and nightlies), try watching FF memory usage, it will go up and down...

I'm on Linux. x86_64, with an Intel GPU (GMA 4500M IIRC)

I'm not sure how much difference hw accel would make since it's firefox that ends up using memory, so it's probably doing this step in software. (and in fact does seem to happen if I set lays.accelerate-none to true)

I don't think you'd actually notice anything in the page I uploaded unless your system is actually hitting swap and waiting on that (which happens to me if I wait a minute or two).

I can still see it if I start a clean profile and run ff with -no-remote (the memory pressure then mostly comes from ff still running my main session).

If you monitor FF memory use/graphics surfaces allocated you should be able to see it create surfaces for several frames, hit gc free them all, then repeat. However that's sort of a side issue, the reason I filed a bug is that it could do it without making a copy since the surface is never written to while the pattern is in use, I think cairo can sometimes detect this sort of thing and avoid copies. 

Possibly this won't be easy to make go away, if the copy can be avoided all together inside cairo it's probably worth figuring out how to make that happen, otherwise not so much.

It might make it slightly more obvious if the canvas was larger (say 1024x1024).

Comment 6

[Thomas Jones]

This is still happening in Firefox nightlies, only now it's easier to say what's going on.

If you start up in a fresh profile, then load the testcase in one window and about:memory in the other, then check the 'Enable Suck' checkbox and refresh about:memory rapidly while watching the value for 'gfx-surface-xlib' it goes up and up and up for a while (it gets to about 250MB for me) then it drops (down to ~2MB for me), and starts going up again. (Obviously there might not be a problem on windows...)

I'm pretty sure I'm not getting layers acceleration (Running Mesa 7.10 with r600 gallium, I'm pretty sure that combo is black listed for GL stuff)

Comment 7

[Thomas Jones]

Just a ping to say, "Still happens" and given that it can use up to 500MB at times might it be good to make it a MemShrink bug?

Comment 8

[Ed Morley [:emorley]]

Thanks for the update - sorry comment 6 got missed. I've marking this as a memshrink bug so it can be assessed/prioritised at the next triage meeting.

Cheers! :-)

Comment 9

[Jeff Muizelaar [:jrmuizel]]

I can reproduce something like this on OS X. At least one of the things that will help with this is bug 681479

Comment 10

[Thomas Jones]

Additional little bit of information, 'gfx-surface-xlib' stays stable if the tab that has my testcase in it is not the active tab in it's window so when testing make certain that it is in a foreground tab.