Page MenuHomePhabricator

clipper is not being set on smart object
Closed, ResolvedPublic

Description

I'm using v8 bindings on efl 1.17.2 with elementary 1.17.1 using elev8-like runtime on wayland backend. the effect occurs when I try to set clip on ElmImage using Evas.Rectangle, if I set clipper before running ecore_main_loop it's invocation starts (...) rendering loop and in evas_render_updates_internal(...) condition if ((!evas_object_clip_get(obj->object)) && (!obj->smart.parent)) on smart object returns true and my clipper is being overridden by framespace clip.

attached snippet

produces visible image and rectangle drawn on it. in theory effect should be exactly the same using node runtime with wayland backend.

I could create a patch addressing that but I wonder what would be the best way to go about it. implementing clip_get for smart object seems a logical step but I noticed quite a lot conditions involving is_smart flag and I don't know whether clip_get isn't meant to return NULL for smart objects (such as ElmImage here).

buniofh created this task.Jul 26 2016, 12:28 PM
buniofh updated the task description. (Show Details)Jul 26 2016, 12:34 PM

following patch

seems to fix the problem.

buniofh assigned this task to zmike.Jul 28 2016, 4:40 AM
raster reassigned this task from zmike to devilhorns.Jul 31 2016, 5:32 PM
raster added subscribers: zmike, raster.

ok. you're working around the problem. the core issue is that evas_render should not be going and doing evas_object_clip_set () at all! what should be happening is the framespace clip should be enforced at RENDER time. when the paint method for that object is called. it should be

ENFN->context_clip_clip(ENDT, ctx, x, y, w, h);

where x, y, w and h are the framespace clip region. whenever rendering TO the backbuffer/primary update buffer this clip should be enforced THIS WAY and not mess with the properties of objects.

note - this also has to happen when figuring out event regions too (just clip the obj coords to framespace clip if not in framespace), as well as with update region calculation in render_pre etc. ... so actually the framespace clip handling code is buggy by design...

@devilhorns! <- :(

raster removed a project: Restricted Project.Jul 31 2016, 5:32 PM

ok, so I poked into this a little bit this morning...

What you are saying Does make sense, however inside the render function (which is a mess btw lol), I cannot find where the object 'paint' method is being called ... any clues ?

raster added a comment.Aug 1 2016, 8:05 AM

obj->func->render() :) for example. you need to account for proxes and map rendering too that is done directly in evas_render.c

just look everywhere ENFN->context_clip_set() or ENFN->context_clip_clip() or any other func is being called... this is where the evas rneder is enforcing the objetc clipping. you want to add some EXTRA clipping here ie clip_clip() that clips the current clip region to the inner framespace area if the obj is not in framespace.

Ohh geez .. silly me was looking for 'paint' .. duh, brain fart ! Thanks :)

Ok, so I have locally implemented these changes ... everything "mostly" works ... except for anything evas_map (for some reason) :( .. also, border icons are gone (in weston) now too :(

Gonna keep poking at it, just wanted to give you an update

@raster

So after several attempts at getting this to work, evas_map objects still will not clip properly :( I put the code into a branch here:

https://git.enlightenment.org/core/efl.git/log/?h=devs/devilhorns/framespace

I tested this by running elementary_test inside Weston and ran through various tests (ie: evas map 3d, Animation, Grid, etc). Everything else is clipping just fine...except for map :/

I don't get it ... tho in all honesty, I know practially nothing about evas_map. Was kind of hoping you could take a peek ??

jypark added a subscriber: jypark.EditedAug 4 2016, 1:20 AM

@devilhorns

I heared the good news. you fix problem in wayland.
before release tizen 3.0, profiling team report some issue, wayland rendering cause more power consumtion than before(X backend)
they said it is because evas_render update inter funtion, clip all the area code. but I troubled find solution, but I heared that you are doing it now.
I really HAPPY!!!!!!!!!!!!!!!!!!
i'll test that your patch solve our problem. thank you~~~

@jypark

Hello :) Well, the issue itself is not fully solved yet. Am still having a problem getting evas_map objects to clip properly. I will let you know when it has been fully solved.

ppiszc added a subscriber: ppiszc.Aug 12 2016, 12:14 AM

@devilhorns
Hello~
I tested your patch and it work well in tizen mobile.
currently, this clipping code make big problem in tizen release.
this issue is one of the release breaker of tizen 3.0.
and we should fix this issue until end of August.

because in X , small rendering only takes 1 ms, but wayland even though update area is big or small, rendering area is always full screen, so render time always take almost 12~13ms.
after summitting your patch , the problem (small update cause a lot of power consumtion because render whole fullscreen area)
is gone.
This is very important issue in tizen. so please check this issue T.T

jpeg added a subscriber: jpeg.Aug 16 2016, 9:19 PM
jpeg triaged this task as High priority.Aug 16 2016, 10:48 PM

This is very important for Tizen.

there is a really simple bug in this... really simple... look closely. just reading the diff made me quickly go "eh? wtf? that doesnt look right..." :)

learning exercise... figure out the REALLY simple bug. :)

buniofh added a comment.EditedAug 17 2016, 3:33 AM

delete_me test seems to be missing and debugs are left on

forget the debugging left on... the issue is in one simple place :) the code would be a lot simpler when fixed... :)

ok can you try upstream git efl now? this should now be fixed...?

I modified evas code to fix this issue.
buniofh, if upstream git fix your problem, please let me know it.

it sure does. thnx :)

devilhorns closed this task as Resolved.Oct 11 2016, 9:01 AM

awesomeness!