GNOME Bugzilla – Bug 702283
some larger size wallpapers not shown
Last modified: 2014-02-25 21:54:04 UTC
Some wallpapers are not shown in the screen shield or on the system background. It appears that this is related to their size. I'm using an exopc with latest fedora 19 packages. We may be hitting the texture size limit.
GL_MAX_TEXTURE_SIZE = 2048
I'm going to attach two possible patches. One by me and one by Jasper. They each tackle the problem in a different way.
Created attachment 246853 [details] [review] background: downscale background to fit in texture limits Some cards have 2k texture limits, which can be smaller than commonly sized backgrounds. This commit downscales the background in this situation, so that it won't fail to load.
Created attachment 246854 [details] [review] background: Allow using sliced textures
Review of attachment 246854 [details] [review]: This has been tested and the result was that it does not work ... we don't know why though. Needs investigation if we want to go that route.
Review of attachment 246853 [details] [review]: ::: src/compositor/meta-background.c @@ +33,3 @@ #include <clutter/clutter.h> +#include <GL/gl.h> We tryed to avoid linking directly to opengl by removing direct GL usage. I don't think adding it back is a good idea. We should get this info from cogl (if does not provide it yet add it to cogl first).
*** Bug 701315 has been marked as a duplicate of this bug. ***
Created attachment 247025 [details] [review] background: Allow using sliced textures for file based backgrounds Some cards have 2k texture limits, which can be smaller than commonly sized backgrounds. One way to get around this problem is to use Cogl's "sliced texture" feature, that transparently uses several hardware textures under the hood. This commit changes background textures loaded from file to potentially use slicing. Based on a patch by Jasper St. Pierre <jstpierre@mecheye.net>.
attachment 247025 [details] [review] is like attachment 246854 [details] [review] but changes the flag for the texture used in file loading, and not for the texture used in gradient loading.
<bpeel> halfline: definetely scaling upfront with gdk_pixbuf would be better <bpeel> wouldn't it make more sense to fit it to the size of the display rather than always trying to load it as big as possible? <halfline> well that has the "hot plug" problem <halfline> we'd have to reload from disk if a big monitor was added <halfline> which we could do <bpeel> yeah, that seems like the best thing to do <halfline> it does mean there might be a user visible latency when plugging in a new monitor <halfline> still, i'll probably look into doing that if the last patch on the bug doesn't work out <bpeel> maybe it could display the old texture in the meantime <halfline> heh, kind of like old progressive scan jpeg files ? <halfline> :-) <bpeel> isn't there a function in GdkPixbuf to load and scale at the same time? I think it does something clever to avoid decompressing all of the JPEG if you're only going to use it at a small size <halfline> there's gdk_pixbuf_new_from_file_at_size <halfline> i don't know if it has any magic under the hood <halfline> bpeel: do you see any issues arising from using slicing ? <halfline> (other than taking up boat loads of texture memory on devices that may not have a lot to begin with) <bpeel> halfline: yes, I was just going to say that cogl-1.14 and cogl-1.16 broke recently so that cogl_texure_new_from_data won't fallback to using a slice texture after it fails to put it in the atlas <bpeel> but there are some patches on the heads of those branches to fix it now <halfline> ahh <halfline> okay <bpeel> alternatively you could pass COGL_TEXTURE_NO_ATLAS instead of COGL_TEXTURE_NONE to work around it
Created attachment 247030 [details] [review] background: Allow using sliced textures for file based backgrounds Some cards have 2k texture limits, which can be smaller than commonly sized backgrounds. One way to get around this problem is to use Cogl's "sliced texture" feature, that transparently uses several hardware textures under the hood. This commit changes background textures loaded from file to potentially use slicing. Based on a patch by Jasper St. Pierre <jstpierre@mecheye.net>.
fwiw, bpeel would rather we scale to the largest monitor and reload from disk on monitor topology changes to conserve texture memory. drago01 proposed saving our scaled outputs to ~/.cache to reduce load times as well.
Review of attachment 247030 [details] [review]: ::: src/compositor/meta-background.c @@ +1061,3 @@ texture = cogl_texture_new_from_data (width, height, + COGL_TEXTURE_NO_ATLAS, So we have cogl fixes. Can't we just depend on newer cogl releases instead of using this workaround?
*** Bug 703180 has been marked as a duplicate of this bug. ***
Review of attachment 247030 [details] [review]: <halfline> drago01: hmm one question is if we even want the texture in the atlas <halfline> does it make sense for big textures ? <halfline> likes backgrounds usually are? <drago01> halfline: that's a good point <ebassi> not really, but if trying to fit a new texture in the atlas fails, it'll end up in another texture anyway; though it probably saves you trying to resize the atlas buffer <Jasper> Isn't the atlas preallocated to be the max texture size? <ebassi> no, I think it's big, but not pre-sized to be max_texture_size <ebassi> but I may be wrong <halfline> ebassi: right, there's a cogl bug fixed in master where it won't transparently end up in another texture <halfline> so the question is do we 1) require new cogl or 2) hardcode NO_ATLAS <ebassi> I'd go for 2 <halfline> okay, thanks => OK
<halfline> drago01: am now <halfline> sup <drago01> halfline: hi, re background texture size thing <drago01> halfline: is there any reason why we can't go back to Jasper's original patch? <drago01> halfline: bpeel said cogl is fixed after all so it should "just work" <halfline> drago01: well his patch didn't work, though that may have been because of a too old cogl <halfline> oh actually his original patch changed the wrong line in the file <halfline> so with that change maybe it does work <halfline> worth trying <halfline> i gave mccann a test srpm at some point but he said it didn't work for him and i didn't pick it back up after that <halfline> like it made the shell crash or something <drago01> halfline: "<bpeel> but there are some patches on the heads of those branches to fix it now" <drago01> halfline: that's https://git.gnome.org/browse/cogl/commit/?h=cogl-1.14&id=c6171434e0ce905fee3a6ea22c804459d69c4524 <drago01> halfline: which isn't in f19 <halfline> drago01: hmm one question is if we even want the texture in the atlas <halfline> does it make sense for big textures ? <halfline> likes backgrounds usually are? <drago01> halfline: that's a good point <ebassi> not really, but if trying to fit a new texture in the atlas fails, it'll end up in another texture anyway; though it probably saves you trying to resize the atlas buffer <Jasper> Isn't the atlas preallocated to be the max texture size? <ebassi> no, I think it's big, but not pre-sized to be max_texture_size <ebassi> but I may be wrong <halfline> ebassi: right, there's a cogl bug fixed in master where it won't transparently end up in another texture <halfline> so the question is do we 1) require new cogl or 2) hardcode NO_ATLAS <ebassi> I'd go for 2 <halfline> okay, thanks
(sorry for the dupe comment, bugzilla told me about the mid-air collision but then posted it anyway when i closed the tab)
Comment on attachment 247030 [details] [review] background: Allow using sliced textures for file based backgrounds ( Leaving open, because I think we could be a lot smarter re: comment 10 ) Attachment 246853 [details] pushed as 15e0115 - background: downscale background to fit in texture limits Attachment 247030 [details] pushed as b7840be - background: Allow using sliced textures for file based backgrounds
*** Bug 722043 has been marked as a duplicate of this bug. ***