In T7811#136684, @bu5hm4n wrote:

@Hermet Something that can be done: You can create the .eo.c files on your local maschine with meson enabled to install .eo files. Then just check them in to the git repository, and build with them. This would result in no need for the user to have the .eo files arround.

@rafspiny, Thanks for your patch but it's not valid anymore.

please add @feature tag in commit message.

Considered again, the intention of this new direction (center align) is hard to deliver since there are CW, anyhow user must read the doc to understand properly.
So IMO, the most simple name is the best in this case = > i.e. EFL_UI_TEXT_PATH_DIRECTION_CW_CENTER?

How about

Please check a comment;

Please check a comment.

In D8892#162887, @kimcinoo wrote:

In D8892#162737, @Hermet wrote:

1. I've considered for the interface, how about using align_hint ?

If the "using align_hint" means kind of "using Efl.Gfx.Hint.hint_align", it could be more flexible than using these enums. But it seems that you did not mean Efl.Gfx.Hint.hint_align because this is hint on how to align an object inside its container.

In D8892#162737, @Hermet wrote:

2. In case of center align, how about pre-computeing "total path_length" then change the start angle internally?

But I do not know how to get the "total path_length" without calling _segment_draw yet. Let me find out, but there will be a similar or duplicated way with what _segment_draw does to get the "total path_length".
IMO this current patch would be better than pre-computing, because there is a pre-computing logic, we need to update both pre-computing and _segment_draw if it has be changed.

1. I've considered for the interface, how about using align_hint ?
2. In case of center align, how about pre-computeing "total path_length" then change the start angle internally?

Please check comments.

Considering caching behavior, this doesn't helpful because Clipping region could be adjustable.
If you draw only valid region, the mask image would be rendered several times whenever clip area is changed.

I have no idea what's your plan for maksing,
Will you make mask images to apply as the clipper if the clipper type is not rect or image?
How about the Line, Vg, Grid, Box whatever else?

Please check a comment.

It looks if the clipping area is frequently changed, the proxy image should be updated more times.
Case by case, this may help for optimal rendering but worse at caching mechanism.

Please check comments.

In D8788#160680, @cedric wrote:

I was thinking of adding the current expected result of the interpolation and the source image into a test. Open them both with evas object image, then compare the image. If result change, something got broken and need investigation.

We can make it simpler.

See a comment.

Please check comment.

In D8757#159659, @CHAN wrote:

I don't see kind of the "gcc=-Wno-clobbered" build options in efl, Do we need to declare variables like this to avoid build warning?

static FILE *binf;
const FILE *binf;
volatile FILE *binf;

In D8857#161723, @segfaultxavi wrote:

Why is using alloca worse than allocating a FIXED SIZE buffer of 2K on the stack?
If you want to limit the maximum buffer size you can do it, and still use alloca, no?

Please move the alloca() outside of the loop,
You don't need to use BLEND_MASK_BUFFER_SIZE all cases.

In D8788#160680, @cedric wrote:

I was thinking of adding the current expected result of the interpolation and the source image into a test. Open them both with evas object image, then compare the image. If result change, something got broken and need investigation

hmm if map object is hidden state?

added example.

In D8788#160316, @cedric wrote:

Could you provide a test from the example you are using to avoid future regression.

update code.

looks good to go, leave verify to zmike.

please consider code consistency.

Please check a comment.

In D8619#157282, @bu5hm4n wrote:

This must be merged when the fix is merged.

Just found out, surprisingly, current wayland egl doesn't support msaa :(

Optimized to keep direct image drawing when msaa is not applied.

In D8552#157188, @Hermet wrote:

In D8552#156850, @Hermet wrote:

In D8552#155457, @raster wrote:

I mean weak performance is "weak point" as you can see the video attached.

Aaah now I understand. :) Yes. Being limited to integer coordinates is ... limiting. It was a decision I made many years ago. Evas_Coord was a typedef and I played with it being optionally double or int, and at the time back in the early 00's ARM didn't have FPUs so there was a real cost using FP coords in the API. I thought doubles may be OK and there was a #ifdef in Evas's headers that allowed you to choose doubles or ints for Evas_Coord, but in the end there was just a bit too much cost in the SW emulated FP code on ARM to stick to this and it also meant that you couldn't have a stable ABI as the ABI might use doubles or ints for coords - I had maybe hoped to be able to compile evas for performance vs accuracy but that wasn't viable this wat. In the end I chose to just go with ints. This then also was reflected throughout most of Evas's code eventually. It was a decision to limit the quality in favor of performance.

Looking back on it I probably should have gone with some kind of fixed-point. Maybe 28.4 (4 bits of sub pixel precision is a lot realistically... and it wouldn't hurt the total canvas space too much, unlike 24.8 would or 16.16). But what is done is done. In theory you could get Evas to effectively provide sub pixel positioning by using a different viewport size vs output size. the whole viewport and output were originally intended to be able to have very efficient scrolling but it just didn't turn out that way as scroll regions were always sub-canvas regions and not the whole canvas. Setting Output to e.g. 100x100 and viewport to 1600x1600 would n theory provide 4 bit sub-pixel precision but now all evas coords need to be multiplied by 16 in both directions to get the same visual look. font sizes too etc. it probably won't even work these days (it used to work... in the early evas days).

Have a look at the performance difference and then let's make a call. It will have some impact on GL perf. Possibly small. If it's small enough then maybe being "always on" is the way to go. If it's bigger then "optional only when needed" would be better.

Here is first test case: expedite comparison
cpu: Intel Core i7, 64bits
window size: 1920 x 1080
loop count per TC: 2000

• Integer coordinates: 10.List: 349fps 20.Blending: 430fps 40.Rotation: 490fps 50.EvasMap: 431fps 70.Text: 397fps
• Floating coordinates: 10.List: 353fps 20.Blending: 429fps 40.Rotation: 494fps 50.EvasMap: 452fps 70.Text: 392fps
  
  There is no any remarkable difference on my laptop.

I'm afraid that how this test precision is trusty, but a memory profiling tool in Tizen apps shows the result like below.

unit: KB
PEAK: peak memory usage of shared and private clean + dirty memory
PSS: Proportional set size

////Integer Coordinate
PEAK PSS APP
30644 10180 calendar
31392 15317 clock
26304 8102 setting
66664 38773 browser

////Floating Coordinate
PEAK PSS APP
33244(+2600) 13056(+2876) calendar
31440(+48) 15632(+315) clock
28652(+2348) 8917(+815) setting
63000(-3664) 36666(-2107) browser

In D8552#156850, @Hermet wrote:

In D8552#155457, @raster wrote:

I mean weak performance is "weak point" as you can see the video attached.

Aaah now I understand. :) Yes. Being limited to integer coordinates is ... limiting. It was a decision I made many years ago. Evas_Coord was a typedef and I played with it being optionally double or int, and at the time back in the early 00's ARM didn't have FPUs so there was a real cost using FP coords in the API. I thought doubles may be OK and there was a #ifdef in Evas's headers that allowed you to choose doubles or ints for Evas_Coord, but in the end there was just a bit too much cost in the SW emulated FP code on ARM to stick to this and it also meant that you couldn't have a stable ABI as the ABI might use doubles or ints for coords - I had maybe hoped to be able to compile evas for performance vs accuracy but that wasn't viable this wat. In the end I chose to just go with ints. This then also was reflected throughout most of Evas's code eventually. It was a decision to limit the quality in favor of performance.

Looking back on it I probably should have gone with some kind of fixed-point. Maybe 28.4 (4 bits of sub pixel precision is a lot realistically... and it wouldn't hurt the total canvas space too much, unlike 24.8 would or 16.16). But what is done is done. In theory you could get Evas to effectively provide sub pixel positioning by using a different viewport size vs output size. the whole viewport and output were originally intended to be able to have very efficient scrolling but it just didn't turn out that way as scroll regions were always sub-canvas regions and not the whole canvas. Setting Output to e.g. 100x100 and viewport to 1600x1600 would n theory provide 4 bit sub-pixel precision but now all evas coords need to be multiplied by 16 in both directions to get the same visual look. font sizes too etc. it probably won't even work these days (it used to work... in the early evas days).

Have a look at the performance difference and then let's make a call. It will have some impact on GL perf. Possibly small. If it's small enough then maybe being "always on" is the way to go. If it's bigger then "optional only when needed" would be better.

Here is first test case: expedite comparison
cpu: Intel Core i7, 64bits
window size: 1920 x 1080
loop count per TC: 2000

• Integer coordinates: 10.List: 349fps 20.Blending: 430fps 40.Rotation: 490fps 50.EvasMap: 431fps 70.Text: 397fps
• Floating coordinates: 10.List: 353fps 20.Blending: 429fps 40.Rotation: 494fps 50.EvasMap: 452fps 70.Text: 392fps
  
  There is no any remarkable difference on my laptop.

Still, I'm skeptic at this since this might increase complexity,

Please check comments.

In D8552#155457, @raster wrote:

I mean weak performance is "weak point" as you can see the video attached.

Aaah now I understand. :) Yes. Being limited to integer coordinates is ... limiting. It was a decision I made many years ago. Evas_Coord was a typedef and I played with it being optionally double or int, and at the time back in the early 00's ARM didn't have FPUs so there was a real cost using FP coords in the API. I thought doubles may be OK and there was a #ifdef in Evas's headers that allowed you to choose doubles or ints for Evas_Coord, but in the end there was just a bit too much cost in the SW emulated FP code on ARM to stick to this and it also meant that you couldn't have a stable ABI as the ABI might use doubles or ints for coords - I had maybe hoped to be able to compile evas for performance vs accuracy but that wasn't viable this wat. In the end I chose to just go with ints. This then also was reflected throughout most of Evas's code eventually. It was a decision to limit the quality in favor of performance.

Looking back on it I probably should have gone with some kind of fixed-point. Maybe 28.4 (4 bits of sub pixel precision is a lot realistically... and it wouldn't hurt the total canvas space too much, unlike 24.8 would or 16.16). But what is done is done. In theory you could get Evas to effectively provide sub pixel positioning by using a different viewport size vs output size. the whole viewport and output were originally intended to be able to have very efficient scrolling but it just didn't turn out that way as scroll regions were always sub-canvas regions and not the whole canvas. Setting Output to e.g. 100x100 and viewport to 1600x1600 would n theory provide 4 bit sub-pixel precision but now all evas coords need to be multiplied by 16 in both directions to get the same visual look. font sizes too etc. it probably won't even work these days (it used to work... in the early evas days).

Have a look at the performance difference and then let's make a call. It will have some impact on GL perf. Possibly small. If it's small enough then maybe being "always on" is the way to go. If it's bigger then "optional only when needed" would be better.

Please check comments.