Closed Bug 552142 Opened 15 years ago Closed 15 years ago

Pixman fast-scale branch performance improvements

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 562087

People

(Reporter: dougt, Unassigned)

Details

Attachments

(5 files, 1 obsolete file)

Add missing file
(deleted), patch
Details | Diff | Splinter Review
oprofile scale_bilinear_no_patch
(deleted), patch
Details | Diff | Splinter Review
oprofile scale_nearest_no_patch
(deleted), patch
Details | Diff | Splinter Review
oprofile scale_bilinear_with_patch
(deleted), patch
Details | Diff | Splinter Review
oprofile scale_nearest_with_patch
(deleted), patch
Details | Diff | Splinter Review
see http://lists.freedesktop.org/archives/pixman/2010-March/000086.html I think we will want this for fennec as soon as possible.
Attached patch Patch against m-c (obsolete) (deleted) — — Splinter Review
Attached patch Add missing file (deleted) — — Splinter Review
Attachment #432303 - Attachment is obsolete: true
Attachment #432304 - Flags: review?(jmuizelaar)
Tested with fennec zoom animation patch According to oprofile results with this patch we are ~2.5x faster. Also we should set ctx.mozImageSmoothingEnabled = false; to avoid bilinear scaling and use nearest scaling.
In 16bpp path with fennec animated zooming we are using fast_composite_scale_nearest_src_0565_0565 function. And yep, now it looks like animated zooming (before it was just too slow that animation was not visible)
I'd rather take this from upstream. Any good reason we can't do that?
> I'd rather take this from upstream. Me too. > Any good reason we can't do that? We can, but it just may take a bit longer when it comes through upstream. Fortunately in this particular case, Alexander Larsson is also from redhat, so I guess this issue got a nice priority boost :)
Fast nearest scaling optimizations have been released in pixman 0.18.0 By the way, could anybody have a look what's wrong with firefox and why it does not want to use normal repeat for tiling in that forum template? http://lists.cairographics.org/archives/cairo/2010-April/019650.html
(In reply to comment #11) > By the way, could anybody have a look what's wrong with firefox and why it does > not want to use normal repeat for tiling in that forum template? > http://lists.cairographics.org/archives/cairo/2010-April/019650.html My guess is that midori doesn't blend between tiles, where as firefox does. Are the tiles zoomed?
Yes, the tiles are zoomed. I just remember that firefox also used repeat in this case earlier and was a bit surprised. Is the blending really necessary? How does it affect performance?
I think we should update pximan to latest upstream with zoom fixes.
(In reply to comment #13) > Yes, the tiles are zoomed. I just remember that firefox also used repeat in > this case earlier and was a bit surprised. Is the blending really necessary? The blended results are what designers likely expect. It's certainly more elegant. > How does it affect performance? It can have a very negative impact on performance, and we are consider removing it...
This should be taken care of by the next pixman update.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Attachment #432304 - Flags: review?(jmuizelaar)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: