After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 708389 - Nearest-pixel interpolation for MetaShapedTexture when possible
Nearest-pixel interpolation for MetaShapedTexture when possible
Status: RESOLVED FIXED
Product: mutter
Classification: Core
Component: general
git master
Other Linux
: Normal enhancement
: ---
Assigned To: mutter-maint
mutter-maint
Depends on:
Blocks:
 
 
Reported: 2013-09-19 17:34 UTC by Hans Petter Jansson
Modified: 2013-10-09 22:51 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Use nearest-pixel interpolation when possible (2.82 KB, patch)
2013-09-19 17:34 UTC, Hans Petter Jansson
needs-work Details | Review
Use nearest-pixel interpolation when possible (2.49 KB, patch)
2013-10-07 15:37 UTC, Hans Petter Jansson
accepted-commit_now Details | Review

Description Hans Petter Jansson 2013-09-19 17:34:38 UTC
Created attachment 255318 [details] [review]
Use nearest-pixel interpolation when possible

MetaShapedTexture should paint itself using nearest-pixel interpolation (COGL_PIPELINE_FILTER_NEAREST) when it's being shown unscaled. This can speed up llvmpipe rendering significantly.

On an old SSE2 box I tried this on, the gnome-shell framerate almost doubled when showing a 1365x964-pixel gnome-terminal on a 1600x1200 desktop. On a modern SSE4 box, the fps increase was between 10% and 20% - still nice.

The relative benefit should be greater when more or bigger windows are being recomposited.
Comment 1 drago01 2013-09-26 16:52:15 UTC
Review of attachment 255318 [details] [review]:

Nice patch, overall looks good but the untransformed check can be either be simplified or extended to work work for clones.

::: src/compositor/meta-shaped-texture.c
@@ +250,3 @@
+   * improves performance, especially with software rendering. If we're
+   * in a clone paint, assume we're being scaled; gnome-shell's overlay
+   * mode uses this.

It is called overview not overlay and we use clones in a other places as well just omit the part about gnome-shell.

@@ +265,3 @@
+      if (tex_width == (guint) (transformed_width + 0.5) &&
+          tex_height == (guint) (transformed_height + 0.5))
+        filter = COGL_PIPELINE_FILTER_NEAREST;

You can just use meta_actor_is_untransformed to find out whether the actor is untransformed (does not work for clone paints though). So you'd have to do "meta_actor_is_untransformed (actor) && !clutter_actor_is_in_clone_paint (actor)" ... alternativly you can use the same approach we use in meta-window-group.c:painting_untransformed which also works for clone paints (if doing nearest in that case gains us anything) otherwise use "meta_actor_is_untransformed (actor) && !clutter_actor_is_in_clone_paint (actor)"
Comment 2 drago01 2013-09-26 17:02:13 UTC
(In reply to comment #0)

> On an old SSE2 box I tried this on, the gnome-shell framerate almost doubled
> when showing a 1365x964-pixel gnome-terminal on a 1600x1200 desktop. On a
> modern SSE4 box, the fps increase was between 10% and 20% - still nice.

Btw. what exactly did you measure? We only redraw when something happens so not sure watching the terminal (unless it is constantly drawing) will tell much.
Comment 3 Hans Petter Jansson 2013-10-07 15:37:30 UTC
Created attachment 256636 [details] [review]
Use nearest-pixel interpolation when possible

Thanks for the review. I've addressed the issues you pointed out. I'm passing pointers to dummy variables x_origin and y_origin since meta_actor_is_untransformed() doesn't take NULL for the arguments. I could've used a single dummy variable, but IMO (..., &dummy, &dummy) would be less readable.
Comment 4 Hans Petter Jansson 2013-10-07 15:56:53 UTC
I've been benchmarking this by running

CLUTTER_SHOW_FPS=1 gnome-shell --replace &

in one tab, then switching to another, where I let

while true; do echo -n '.'; sleep 0.01; done

run. After a little while, I switch back to the gnome-shell tab and eyeball the median frame rate. The numbers tend to be very consistent. It's a low-tech approach, but it works as long as I don't need high precision or comparisons across more than a single test environment.

In the long term, it'd be nice to have a better way to evaluate the performance, though.
Comment 5 drago01 2013-10-07 16:30:58 UTC
Review of attachment 256636 [details] [review]:

OK looks good ... I wonder why cogl does not do this for us already but well.

Do you have a git account?
Comment 6 Hans Petter Jansson 2013-10-07 17:47:50 UTC
Yes. I'll push it. Thanks!
Comment 7 drago01 2013-10-09 21:03:42 UTC
(In reply to comment #6)
> Yes. I'll push it. Thanks!

OK, try to push it soon though (3.10.1 tarballs are due on Monday).
Comment 8 Hans Petter Jansson 2013-10-09 22:51:24 UTC
Done.