in gl engines, orientation is applied during the draw. this is different from
sw engines where the orientation is directly applied to the internal pixel data
which results in a state change of the object internals.
this preserves image cache state and allows the image to be loaded normally instead
of displaying a black rectangle if orientation is set prior to a texture being
created
@fix
Depends on D8916
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
It seems that this patch has no reviewers specified. If you are unsure who can review your patch, please check this wiki page and see if anyone can be added: https://phab.enlightenment.org/w/maintainers_reviewers/
Actually, Evas_GL_Image could be shared among images as it's optimal, what makes texture loading fails?
| src/modules/evas/engines/gl_generic/evas_engine.c | ||
|---|---|---|
| 1140 | Failed to load texture here? What is the reason exactly? | |
| src/modules/evas/engines/gl_generic/evas_engine.c | ||
|---|---|---|
| 1140 | This case only works if the texture is already loaded. If you run src/examples/elementary/image_example_01 in GL you should only see a black rect due to this bug. | |
The weird bit is that I would expect evas_gl_common_image_update to actually load the texture. @zmike do you have an idea why the texture is not loaded in that case?
This only loads the texture if it has previously been prepared for drawing. In the given scenario, this codepath is triggered during object construction and so no such preparation has occurred.
Hum, I am guessing that in this case, there isn't any texture available, maybe not even a valid width, height and color space. Maybe do a test on the texture and switch between the two possible function for creating image. As @Hermet pointed out, I am also afraid that the new_from_rgbaimage will either leak a texture if one is available or duplicate image.