Page MenuHomePhabricator

evas gl: move to floating point coordinate system.
ClosedPublic

Authored by Hermet on Apr 4 2019, 1:08 AM.

Details

Summary

GL engine has used integer coordinates system since it's born though
OpenGL basically uses floating point vertex coordinates system.

There were many dissatisfaction, complaints about this
since object's transition is jiggled, not perfectly smooth.

It's obvious because Positioning must be stepping with integer units
without any subpixel rendering.

Our gl engine currently supports msaa options and evas map allows to
have double precivion coordinates system, our engine must do handle this over as well,
to work together.

If you don't like change,

We could switch behaviors optionally (turn on, only when msaa is enabled)
But I think it's pointless using integer coordinates system in GL thesedays.
It just make code complex to maintain.

There will be an additional patch coming for SW backend map behavior soon.

Left: before patch
Right: after patch

Diff Detail

Repository
rEFL core/efl
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
Hermet created this revision.Apr 4 2019, 1:08 AM

It seems that this patch has no reviewers specified. If you are unsure who can review your patch, please check this wiki page and see if anyone can be added: https://phab.enlightenment.org/w/maintainers_reviewers/

Hermet requested review of this revision.Apr 4 2019, 1:08 AM
Hermet edited the summary of this revision. (Show Details)
raster requested changes to this revision.Apr 4 2019, 1:15 AM
raster added a subscriber: raster.

this has a downside. it doubles the memory needed for coord storage/copying to gpu etc. .... that will mean some performance drop and the only benefits are when using msaa... but even then evas object geometry is done with integers only so it can only help with map and even then map reduces to integers anyway at the engine api....

This revision now requires changes to proceed.Apr 4 2019, 1:15 AM
Hermet edited the summary of this revision. (Show Details)Apr 4 2019, 1:16 AM
Hermet added a comment.EditedApr 4 2019, 1:24 AM

this has a downside. it doubles the memory needed for coord storage/copying to gpu etc. .... that will mean some performance drop and the only benefits are when using msaa... but even then evas object geometry is done with integers only so it can only help with map and even then map reduces to integers anyway at the engine api....

I don't know how many users would have serious burden because of this, these days,
But obviously, efl animation show us very weak performance than other decent frameworks.

if you say so, we could compromise this floating point coordinate system optionally,
What do you think?

Hermet edited the summary of this revision. (Show Details)Apr 4 2019, 1:30 AM
raster added a comment.Apr 4 2019, 8:58 AM

But obviously, efl animation show us very weak performance than other decent frameworks.

what is the weak performance specifically? can you expand on this?

if you say so, we could compromise this floating point coordinate system optionally

well it'd be good to have some measurement on the speed hit - especially something like lots of text rendering where a lot of coordinates will be provided (like a screen full of text).

Hermet added a comment.EditedApr 4 2019, 7:32 PM

But obviously, efl animation show us very weak performance than other decent frameworks.

what is the weak performance specifically? can you expand on this?

if you say so, we could compromise this floating point coordinate system optionally

well it'd be good to have some measurement on the speed hit - especially something like lots of text rendering where a lot of coordinates will be provided (like a screen full of text).

I mean weak performance is "weak point" as you can see the video attached.
It's simple case but there have been many complaints in using animation in EFL because of this. jiggled not smooth even I don't like to allow this animation quality.

I think devices which we should focus on (what is the major targets?) are not much poor as they can't allow this floating system. Otherwise, minor cases.

Next week maybe i could measurement, soon i would share you.

and "optionally" means we could perform this only when msaa is enabled.

Hermet added a comment.Apr 4 2019, 7:38 PM
This comment was removed by Hermet.
raster added a comment.Apr 5 2019, 3:46 AM

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.

Hermet added a comment.EditedApr 17 2019, 1:17 AM

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.

raster accepted this revision.Apr 17 2019, 1:29 AM

yup. no big difference. ok. i'm comfortable with moving to float entirely.

This revision is now accepted and ready to land.Apr 17 2019, 1:29 AM

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

Hermet added a comment.EditedApr 17 2019, 10:31 PM

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

The last test case: expedite memory comparison using Massif and same environment of first expedite test case.

The peak memory is almost same and nvidia driver memory usage shows me any difference neither.
Only difference between two version is _pipebuf_resize() in the gl common, which would allocate more memories for the vertices since the coordinate element size is increased by 2bytes (short ->float)
And it brings memory increase by 40kb average but i think it's ignoreable number of size.

Hermet updated this revision to Diff 21445.Apr 17 2019, 11:43 PM

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

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

Hermet planned changes to this revision.Apr 18 2019, 12:52 AM
This revision was not accepted when it landed; it landed in state Changes Planned.Apr 18 2019, 4:11 AM
This revision was automatically updated to reflect the committed changes.