Page MenuHomePhabricator

image rendering fails with no feedback and then never renders
Closed, InvalidPublic

Description

This has been showing up in various forms for some time and I think at least some aspect of it needs to be fixed since it causes compositor issues:

  1. Have image object
  2. Set pixels dirty, add update region
  3. Render occurs, image doesn't render because e.g., obj->cur->cache.clip.visible is false and evas_object_is_active() returns false
  4. User has no idea that image never rendered, image does not render

It seems to me that it's not the user's responsibility in this case to babysit evas and make sure that it eventually renders the image?

ManMower raised the priority of this task from High to Showstopper Issues.Jul 6 2017, 12:53 PM
ManMower added a subscriber: ManMower.

I think I ended up at the bottom of this same rabbit hole trying to figure out why wayland clients don't update on the pager when they're not on the current desktop.

Object marked as dirty, no pixels_get callback ever fires for it.

E relies on the pixels_get callback firing to register wayland surfaces for frame callbacks during render post.

jpeg added a comment.Jul 11 2017, 12:30 AM

Any test code?
As far as I know, the flag cache.clip.visible can only be false if the object itself is not visible, or one of its (recursive) clippers makes it invisible by color or visibility flag.

jpeg added a comment.Jul 16 2017, 11:48 PM

To me this all sounds like Evas has no knowledge that the image is meant to be visible, because it isn't. What the pager is doing is basically making a proxy image, but without using evas' proxy images. It actually sounds like there should be a proxy image instead?

zmike added a comment.Jul 20 2017, 8:03 AM

See T5370, this is a 100% reproduction case.

raster added a subscriber: raster.Jul 20 2017, 8:06 PM

wait wait.... why does this then work in x11 with images updating on other desktops? why would wl and x11 be different? from memory proxy isnt even used. just multiple image objects all use native surface pointing to the same pixmap (or buffer). e_comp has an api for mirroring a window ... this was all implemented before we had proxies... so cur cache visible would be false if the object is not visible...

yes - if the original window image itself is not visible, pixel get will not be called. that is its definition of working. evas MAY at its discretion not call it if it believe s the pixels won't be needed. that's the entire point of the pixel callback. if you don't want this then you can directly just "modify pixels, add updates" explicitly to the object. pixel_get is intended for when getting pixels is costly (requires e.g. grabbing data or calculating a mandelbrot set content) and so avoid calling it if evas is sure the pixels won't be needed.

jpeg added a comment.Jul 20 2017, 9:26 PM

I agree with @raster in the sense that this is not an issue with Evas. E has basically been making manual image proxies and this works under X since the clients will send new pixmaps all the time, while under WL the compositor should request a new frame.
I think we should consider using evas image proxy instead of all the custom code in E. And yeah, that might mean adding some of the conversion routines inside Evas.

zmike added a comment.Jul 21 2017, 9:22 AM
In T5678#92289, @jpeg wrote:

I agree with @raster in the sense that this is not an issue with Evas. E has basically been making manual image proxies and this works under X since the clients will send new pixmaps all the time, while under WL the compositor should request a new frame.
I think we should consider using evas image proxy instead of all the custom code in E. And yeah, that might mean adding some of the conversion routines inside Evas.

Ignore @ManMower, this is is a real issue in evas when running under X (as in the referenced ticket) and an issue with evas in general. evas_object_visible_get() returns true for an object, the above steps are taken, and the image may or may not be rendered; if it is not rendered then the user has no way of knowing.

It would lead to other breakage I think if we change the behavior of pixels get to always trigger even when the object is not displayed on screen (visibility != displayed). Can you rely on RENDER_POST callback at all to do the cleanup ? I have no idea what you are doing during that callback, so not to sure of what needs to be done. Could you explain quickly the step taken during that callback that create problems if they are not taken ?

jpeg added a comment.Jul 27 2017, 12:11 AM

I removed T5370 as a subtask: it's not related.
I also want to close this as "Invalid" as the flags are all correct, the image is not visible from Evas point of view, thus it should not be rendered. This means no call to pixels_get cb.
That being said, this is a real issue, and E will need to find another way to request a buffer from a wayland window. (Also, talking with @raster I think we mentioned there is even some kind of timing issue here, as get_pixels is too late to request a new buffer. get_pixels should just return the buffer that should already be there and ready to show).

jpeg lowered the priority of this task from Showstopper Issues to High.Jul 27 2017, 12:11 AM
bu5hm4n moved this task from Backlog to rendering on the efl board.Jun 10 2018, 12:34 PM
zmike edited projects, added Restricted Project; removed efl.Jun 11 2018, 6:54 AM
zmike edited projects, added efl: rendering; removed Restricted Project.Jun 11 2018, 7:41 AM
raster closed this task as Invalid.Jul 16 2018, 2:09 AM

this has been lurking for a while and me, jpeg and cedric all said basically "it's invalid". pixel get cb is not called every render if the obj is visible. it's called evas thinks the obj needs rendering. it may not actually be rendered or be visible to the user/output of the canvas, but evas thinks it needs it.. then it'll call it, but it was never a "call always at every render if this obj is visible logically at all". as jpeg said a render pre/post could do this and iterate over all the obj's that need this but it's not what the pixel get cb is for. so finally doing what jpeg said.. closing as invalid. :)

find another way to request a buffer. as such at least in e when you have a pager all desktops are visible. so all visible windows across all screens need to send frame requests to clients. for currently not visible desktop e could throttle the rate to every 2nd or 4th frame or something or a specific framerate with a timer (since being exactly right now doesn't matter as it's a reduced framerate). for iconified/minimized windows they shouldn't be sending frame reuests until a copy of that window is visible (e.g. like ibar uses) and then it could either send full framerate requests or throttle - a property on the comp mirror obj could determine this. it could be done even in the pager - it can switch the property from full, to slow to none or something as you switch desktops, then the real window is sent the "highest rate" from all the mirrors if the original window is not visible. just throwing out some ideas on how things should be solved, but not in evas and the pixel vb... :)