Page MenuHomePhabricator

canvas map: introduce a new texture mapping for better quality.
ClosedPublic

Authored by Hermet on Mar 6 2019, 4:19 AM.

Details

Summary

This new implementation of evas map texture mapping
is designed for high quality rendering same level to GL.

If you use a high-end device, performance is not too bad, you can turn this on.
You might have practical image quality even in software rendering.

Since this implementation still have a few optimization points (+simd)
and stablizings, it may be useful in somewhat limited envrionments right now.
However the functionality definitely works fine, so please turn this on by
demand (anti_alias + smooth) for a while.

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.Mar 6 2019, 4:19 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.Mar 6 2019, 4:19 AM
Hermet edited the summary of this revision. (Show Details)Mar 6 2019, 4:33 AM
Hermet edited the summary of this revision. (Show Details)
Hermet edited the summary of this revision. (Show Details)
Hermet planned changes to this revision.Mar 6 2019, 4:41 AM

Neat. It would be great if that could become a flag on efl_gfx_mapping.eo (I can imagine, for example, that during animation we would be fine to drop precision and just turn it on at the end of an animation). Anyway, this patch can not land at this point in time, remind me to do a better review after the release.

Hermet updated this revision to Diff 20124.Mar 6 2019, 6:45 PM

clean up code.

Hermet updated this revision to Diff 20125.Mar 6 2019, 8:24 PM

clean up code.

Hermet edited the summary of this revision. (Show Details)Mar 6 2019, 8:25 PM

Neat. It would be great if that could become a flag on efl_gfx_mapping.eo (I can imagine, for example, that during animation we would be fine to drop precision and just turn it on at the end of an animation). Anyway, this patch can not land at this point in time, remind me to do a better review after the release.

Sure, right moment this will work at this condition (smooth + anti_alias)
I may blog for better understanding this implementation by reviewers later.

Hermet updated this revision to Diff 20126.Mar 6 2019, 9:11 PM

clean up code.

devilhorns requested changes to this revision.Mar 6 2019, 10:28 PM
devilhorns added a subscriber: devilhorns.

Just being a blocker until this can be read, re-read, and agreed apon. Seems to be a lot of cookie-cutter Patch Accepting going on lately.....Let's calm down a minute until we have time to Properly Review...

This revision now requires changes to proceed.Mar 6 2019, 10:28 PM
raster added a subscriber: raster.Mar 7 2019, 12:35 AM

what's the performance difference on a range of devices/architectures?

devilhorns resigned from this revision.Mar 7 2019, 3:18 AM

Now that someone with some knowledge is in attendance, I will stop being a blocker here ;)

what's the performance difference on a range of devices/architectures?

Didn't test yet, I guess the performance diff won't be remarkable on the high-end devices such as desktop.
Just assume the possibilities among low-end devices plus big region of map drawing.
However, this logic is obviously not optimized enough and more computational than original map logic.
I will try profiling and share the result later.

Here anti-aliasing code could be replaced by bilinear interpolation as smooth scaling does.
and basic computations could be improved by vector processing per architectures.
First thing is easier by me but second one must be a additional future job by me or someone else.

Additionally, this map drawing works on the triangle-list (not quadron), evas_map api could afford arbitrary map points count, 3 ~ N
like the traditional opengl triangle list to compose complex meshes.
In this case, user could compose more complex shapes(like a page flip, textpath) using smaller polygons with this.

Most of all, the original drawing quality is too bad to use, specially in products, we can't satisfy with the quality.
I tried to improve the arithmetic computations of the original map logic but failed.
There is no possible improvement by me. Rather than that, introducing this new algorithm works and simple.

Right moment, we can start with this implementation for better quality map raster. it could be worked optionally (as Cedric suggested)
When this logic is mature to use, we can replace original one with this.

Hermet added a comment.EditedMar 13 2019, 1:45 AM

Here is a my performance comparison on my intel core i7 laptop.
Here number indicates the elapsed time(ms) for performing map drawing

  1. 800x800 Image Rotation (Bilinear Sampling)

original(mmx): 0.0083ms,
new: 0.0116ms
1.4x slower

  1. 800x800 Image Rotation (Point Sampling)

original(mmx): 0.0026ms,
new: 0.0021ms
1.18x faster

  1. 400x400 Image Rotation (Bilinear Sampling)

original(mmx): 0.0016ms,
new: 0.003ms
1.88x slower

  1. 800x800 Image Rotation (Point Sampling)

original(mmx): 0.0005ms,
new: 0.0006ms
1.14x slower

  1. 1200x1200 Image Rotation (Bilinear Sampling)

original(mmx): 0.0153ms,
new: 0.0286ms
1.86x slower

  1. 1200x1200 Image Rotation (Point Sampling)

original(mmx): 0.0053ms,
new: 0.0055ms
1.04x slower

  1. elementary textpath (80 pieces maps)

original(mmx): 0.000762ms,
new: 0.002921ms
3.83x slower

raster accepted this revision.Mar 19 2019, 4:06 PM

aaah ok. that's a good selection there. thanks! :) so impact can vary from almost nothing to "pretty big". at least it's an option - aa and smooth on at the same time i think is good enough. if it was not that much more i was going to suggest we adopt it as the default "smooth". :)

This revision is now accepted and ready to land.Mar 19 2019, 4:06 PM
Hermet updated this revision to Diff 20917.Mar 25 2019, 3:07 AM

clean up code.

Hermet updated this revision to Diff 20918.Mar 25 2019, 3:09 AM

clean up code

Hermet updated this revision to Diff 20919.Mar 25 2019, 3:10 AM

clean up code.

This revision was automatically updated to reflect the committed changes.

@Hermet I just noticed this patch introduces warnings:

[354/2186] Compiling C object 'src/lib/evas_goal/c61fe7f@@evas@sha/.._evas_common_evas_map_image.c.o'.
In file included from ../src/lib/evas/common/evas_map_image.c:654:0:
../src/lib/evas/common/evas_map_image_internal_high.c: In function ‘_map_triangle_draw_linear.constprop’:
../src/lib/evas/common/evas_map_image_internal_high.c:460:101: warning: ‘c[3]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
                   DATA32 tmp = (((int) c[0]) << 24) | (((int) c[1]) << 16) | (((int) c[2]) << 8) | ((int) c[3]);
                                                                                                    ~^~~~~~~~~~~
../src/lib/evas/common/evas_map_image_internal_high.c:460:80: warning: ‘c[2]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
                   DATA32 tmp = (((int) c[0]) << 24) | (((int) c[1]) << 16) | (((int) c[2]) << 8) | ((int) c[3]);
                                                                               ~^~~~~~~~~~~
../src/lib/evas/common/evas_map_image_internal_high.c:460:57: warning: ‘c[1]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
                   DATA32 tmp = (((int) c[0]) << 24) | (((int) c[1]) << 16) | (((int) c[2]) << 8) | ((int) c[3]);
                                                        ~^~~~~~~~~~~
../src/lib/evas/common/evas_map_image_internal_high.c:460:34: warning: ‘c[0]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
                   DATA32 tmp = (((int) c[0]) << 24) | (((int) c[1]) << 16) | (((int) c[2]) << 8) | ((int) c[3]);
                                 ~^~~~~~~~~~~

Indeed, if col_blend is false, the c[] array will be uninitialized.

hermet. you need to take a good hard loo at this. i''m seeing coordinates that are negative and i think other out of bounds coordinates as well. you need to have extensive tests with different resolution input, output, many angles and so on... i've already put a quick and dirty fixup for negative uv coords, but even with that i see rendering bugs in some cases. :)