Hi Cedric,
That may be another bug, we did not test but the current patch indeed
fixes the problem, discarding the previous surface sooner than later.
If you want another function, there is no need to mark it as
dirty/changed, just isolate the mapped surface cleanup code into a
function, call it from everywhere (the one that checks if there is a
map and its surface, deleting them) -- no need for a new flag, but I
like your proposed name evas_object_content_change()
On Wed, Feb 27, 2013 at 11:28 PM, Cedric BAIL <cedric.b...@free.fr> wrote:
> On Thu, Feb 28, 2013 at 2:52 AM, Paulo Cavalcanti <pca...@zytor.com> wrote:
>> Ederson Souza <eder...@profusion.mobi> writes:
>>> I'd like to inform about a bug I've found in Edje. If one tries to change
>>> the text of a TEXT part using a rotation transition, the text will only be
>>> changed if new text size is different from previous one. If not, it will
>>> show the animation, but the text won't change.
>>> I've realised that if the map is not enabled, changing the text works, but
>>> without the animation.
>>> I've attached an example, that can be tested with edje_player. If you send:
>>>
>>> message 1 INT 1
>>> message 1 INT 2
>>> message 1 INT 20
>>> message 1 INT 30
>>> message 1 INT 5
>>>
>>> You will see the animation all times, but just when the text size changes,
>>> the text will be changed (it will show 1, 1, 20, 20, 5 instead of 1, 2, 20,
>>> 30, 5).
>>> Any clues?
>>
>> The problem with the changed text of same size as the previous one that
>> doesn't get rendered correctly is because evas_render_mapped() doesn't
>> free current map surface for rendering a new one instead - since both
>> surface and text object had the same size and render wouldn't know to
>> handle that case specifically.
>>
>> Here goes two patches: the first patch fixes this bug in
>> evas_object_text_text_set() and the other is just a backported version
>> of the original patch.
>
> I now understand your problem. I still have a few question. What
> happen if you rotate an edje object with a GROUP part that has an
> animated text in that group. My guess looking at the code is that it
> wont work also.
>
> I also think that if you change the font and pick one that doesn't
> change the size of the rendered text, the same issue will happen. I
> believe that textgrid font/text/palette change will also not affect
> the mapped surface. Maybe even textblock will be affected by this
> issue. I think we need a way to tell that the content of the widget
> change to evas_render_mapped, so that we could add that to the
> surface_{w,h} != s{w,h}. Something like an evas_object_content_change.
>
> If any of those point are true, I think that your patch is not the
> correct one. If I am wrong, then I will push it.
> --
> Cedric BAIL
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
