Page MenuHomePhabricator

elementary: improving performance and useability text widgets
Open, NormalPublic


There are many issues for elm_entry, elm_label about the following reasons.
So, we have to discuss improving performance of elm_entry widget and deprecating elm_label widget.
Or making a new integrated widget for text.

  • elm_entry

1. Performance
Adding the elm_entry widget object has big performance problems.
It changes its group(theme) when some API is called.
ex) elm_entry_single_line_set()

Let's imagine if I want to show non-editable singleline entry. The elm_entry will try to
load theme 3 times. (default -> singleline -> non-editable singleline)
Changing theme multiple times waste a lot of time.

Additionally, some features could be prepared when the feature is really needed.
ex) _edje_entry_real_part_init()

2. Size calculation
The elm_entry widget uses a job for calculating its size. Because of this,
we can see some flickering issues in low performance device when a container contains elm_entry objects.
And many of developers wonder why elm_label and elm_entry have different size calculation logic.
At least, when elm_entry is not scrollable, elm_entry and elm_label must have same calculation logic and result.

3. Hard to customize its theme.
As I mentioned in the performance section, elm_entry needs many groups for supporting all of its properties.
Because of some reasons, application developers wanted to customize a theme of elm_entry widget.
And they faced a bunch of groups and mysterious properties. (source#, entry_mode, multiline, etc...)
Those properties could be used for all of other groups. But, not working.
Some of developers expect to see editable textblock part when they use "entry_mode: EDITABLE".
I think we need to reorganize Edje groups and properties for elm_entry.

  • elm_label

1. Lack of feature
In comparison with elm_entry, many of features are not supported for elm_label.
selection, item provider(even default image loading), scrollable and etc.
We were recommend to use elm_label width for non-editable text field and performance.
But, because of features, developers change elm_label to elm_entry.
In spite of its low performance.

id213sin created this task.Mar 2 2016, 11:10 PM

For eo interfaces work we are deprecating label and making it an entry just with editing and selection off (by default) because it inherits from entry these can be turned on. of course this will then perform as well as entry does. :)

as for changing group eo allows this to be optimized by eo_add - we have a finalize on object creation and edje object add/file set can deferred until finalize. ie

eo_add(&obj, CLASS_ENTRY, parent,
       efl_theme_style_set(obj, "mystyle"),
       efl_entry_single_line_set(obj, EINA_TRUE),
       efl_text_set(obj, "Hello World", NULL));

something like that can defer work until after finalizing which is called after the efl_* methods are called to do setup on creation. :)

We can't re-organize the edje setup without breaking themes - we can provide people with template edc files to go modify to do their own custom styles with to save them time, but an entry does require a cursor and selection objects - that's how it works. you can just leave them alone if you don't want to customize from the template, but provide a template and extensive docs on customizing. :)

tasn added a comment.Mar 4 2016, 4:46 AM

@raster already covered most of it. Label is going to be a thin wrapper around entry with a few different defaults. Performance won't be a problem anymore thanks to eo_add, and everything will be covered with rainbows.

As for the size calculation logic: because label will be an entry, it'll be the same. As for the job: we should probably do a preliminary calculation as soon as we set the text, so for example calculate according to the first X bytes, and then put a job to calculate the real size, so even on slow devices we will have a reasonable first size to prevent the flicker. I don't remember what we actually decided we'll do for async objects, but this was one of the options.

@raster, @tasn
Thank you for opinions.
But, I'm worrying about using eo_add() for solution of performance.
I think it does not improve the performance the application which is using legacy APIs.
And, can I use it for C++ or java binding? I guess we can use eo_add() only in C language.

I know re-organizing the edje for elm_entry will break old themes.
So, we suggested to add new widget for text if there is no way to support old themes.

I still think theme has to be used only for its look and feel as far as possible.
But, currently, almost all of functionalities of elm_entry are relying on its edje groups too much.

@tasn, @herdsman
By the way, after applying your patches:

I can see the performance for elm_entry, elm_label is improved.

Adding elm_entry widget (singleline, non editable, non scrollable)

  • Before: average 0.00213
  • After: average 0.00194 (9% improved)

Adding elm_label widget (singleline)

  • Before: average 0.000668
  • After: average 0.000559 (17% improved)

It shows huge improvement.
Thank you for the patches. :)

  1. eo_add for c+/js would be via closure/lambda provided to the constructor - the content of the lambda/closure is the same as the method calls in eo_add. we discussed this already
  2. no it won't help with legacy api's - this is good reason to encourage people to use the new api's. if you add a n ew widget it won't help people on legacy api's anyway.. they have to change code. peolpe CAN use eo api WITH legacy like obj = eo_add(); evas_object_show(obj); - it works just fine. :) so this is equivalent to you saying "make a new widget" :) code has to be changed - here just change the creation to use eo api.
  3. as for performance - it's simply a matter of getting good samples we can profile and dig into "why is this being stupid". sure - setting style (edje object 3 times) is a bit bad, but we could actually improve edje to "on demand create" objects like parts (only create once edje object is visible and defer until smart calc time for creation). this would benefit both new api's and old as it's reducing the costs of a "temporary creation" and it also cuts down costs for parts that are never made visible (like images, rects etc. - we still kind of need it for text/textblock). this is just optimizing. like the patches above you mention - that was a result of @singh.amitesh pointing out a specific thing we could test (bouncing text) and then dig in and fix.
tasn added a comment.Mar 8 2016, 7:25 AM

Happy my patches helped. :) It was a stupid regression that shouldn't have been there in the first place...

Again, raster got me to it, I agree with him.

@raster, @tasn
We(I and @herdsman) were working on merging elm_entry and elm_label.
The main plan was changing elm_label to inherit elm_entry.
But, elm_entry has a lot of features. If elm_label inherits elm_entry,
we need to support elm_entry's features on elm_label.
But, it would break backward compatibility for elm_label. Especially, customized theme for elm_label.
(As you know, we need to provide 100% backward compat for API and theme in Tizen)

So, as @woohyun's opinion, we are going to change the plan.
elm_entry will inherit elm_label. And going to make text interfaces for both widgets.

stefan_schmidt removed a project: Restricted Project.Jul 20 2016, 7:38 AM

most of this is solved now with eo/interfaces merge... right? we need to of course continue and profile and fix.. but the merge fixed lack of features. beyond that.. profile, test, fix. ?

zmike edited projects, added Restricted Project; removed efl.Jun 11 2018, 6:59 AM
bu5hm4n edited projects, added efl: widgets; removed Restricted Project.Jun 11 2018, 9:16 AM