Page MenuHomePhabricator

Hermet (Hermet Park)
Engineering

Projects (9)

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Thursday

  • Clear sailing ahead.

User Details

User Since
Feb 19 2013, 12:12 AM (326 w, 3 h)
Availability
Available

Email: hermetpark@gmail.com
Blog: hermet.pe.kr

Recent Activity

Today

Hermet added a comment to T7811: Enventor fails to compile with latest EFL library.

@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.

Tue, May 21, 4:16 AM · Restricted Project, Enventor
Hermet added a comment to T7811: Enventor fails to compile with latest EFL library.

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

Tue, May 21, 1:26 AM · Restricted Project, Enventor

Yesterday

Hermet closed D8892: Efl.Ui.Textpath: support center align for each direction.
Mon, May 20, 10:31 PM · efl
Hermet accepted D8892: Efl.Ui.Textpath: support center align for each direction.
Mon, May 20, 10:30 PM · efl
Hermet requested changes to D8892: Efl.Ui.Textpath: support center align for each direction.

please add @feature tag in commit message.

Mon, May 20, 6:48 PM · efl
Hermet closed D8924: Efl.Ui.Textpath: draw text immediately in the position.set.
Mon, May 20, 6:48 PM · efl
Hermet accepted D8924: Efl.Ui.Textpath: draw text immediately in the position.set.
Mon, May 20, 6:46 PM · efl
Hermet requested changes to D8892: Efl.Ui.Textpath: support center align for each direction.

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?

Mon, May 20, 3:53 AM · efl
Hermet added a comment to D8892: Efl.Ui.Textpath: support center align for each direction.

How about

Mon, May 20, 3:42 AM · efl

Thu, May 16

Hermet closed D8895: evas_vg_node: Move change flag value setting.
Thu, May 16, 6:44 PM · efl
Hermet accepted D8895: evas_vg_node: Move change flag value setting.
Thu, May 16, 6:43 PM · efl
Hermet requested changes to D8895: evas_vg_node: Move change flag value setting.

Please check a comment;

Thu, May 16, 6:37 PM · efl

Wed, May 15

Hermet requested changes to D8895: evas_vg_node: Move change flag value setting.

Please check a comment.

Wed, May 15, 1:21 AM · efl

Tue, May 14

Hermet closed D8873: ector_software_rasterizer: Improved masking calculation..
Tue, May 14, 7:22 PM · efl
Hermet accepted D8873: ector_software_rasterizer: Improved masking calculation..
Tue, May 14, 7:21 PM · efl
Hermet added a comment to D8892: Efl.Ui.Textpath: support center align for each direction.
  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.

  1. 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.

Tue, May 14, 7:19 PM · efl
Hermet requested changes to D8892: Efl.Ui.Textpath: support center align for each direction.
  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?
Tue, May 14, 5:45 AM · efl
Hermet requested changes to D8873: ector_software_rasterizer: Improved masking calculation..

Please check comments.

Tue, May 14, 3:48 AM · efl

Mon, May 13

Hermet requested changes to D8881: evas/render: size and draw proxy render surface based on proxy clipper.
Mon, May 13, 6:30 PM · efl
Hermet requested changes to D8841: evas/render: clamp mask surface size to clipper size.

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.

Mon, May 13, 2:52 AM · efl: rendering
Hermet requested changes to D8852: evas: enable setting any object as a clipper.
Mon, May 13, 1:49 AM · efl
Hermet added a comment to D8852: evas: enable setting any object as a clipper.

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?

Mon, May 13, 1:49 AM · efl
Hermet added inline comments to D8852: evas: enable setting any object as a clipper.
Mon, May 13, 1:42 AM · efl
Hermet accepted D8878: add a clipped textblock proxy test.
Mon, May 13, 1:41 AM · expedite
Hermet requested changes to D8880: evas/render: fix proxy clipping when source_clip is disabled.

Please check a comment.

Mon, May 13, 1:39 AM · efl
Hermet added a comment to D8881: evas/render: size and draw proxy render surface based on proxy clipper.

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.

Mon, May 13, 1:33 AM · efl
Hermet requested changes to D8873: ector_software_rasterizer: Improved masking calculation..

Please check comments.

Mon, May 13, 12:28 AM · efl

Sun, May 12

Hermet added a comment to D8788: evas png: apply interpolation when scale down image loading..

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.

Sun, May 12, 11:53 PM · efl
Hermet added reviewers for D8886: evas example: add a png scale down example.: cedric, committers.
Sun, May 12, 11:50 PM · efl
Hermet requested review of D8886: evas example: add a png scale down example..
Sun, May 12, 11:49 PM · efl
Hermet closed D8788: evas png: apply interpolation when scale down image loading..
Sun, May 12, 11:46 PM · efl
Hermet closed D8875: Efl.Ui.Textpath: enhance to support legacy API.
Sun, May 12, 9:09 PM · efl
Hermet accepted D8875: Efl.Ui.Textpath: enhance to support legacy API.
Sun, May 12, 9:08 PM · efl
Hermet closed D8885: docs: Fix a wrong ingroup name of textpath..
Sun, May 12, 9:06 PM · efl
Hermet accepted D8885: docs: Fix a wrong ingroup name of textpath..
Sun, May 12, 9:05 PM · efl

Fri, May 10

Hermet requested changes to D8875: Efl.Ui.Textpath: enhance to support legacy API.

We can make it simpler.

Fri, May 10, 4:52 AM · efl

Thu, May 9

Hermet closed D8869: ector_software_rasterizer : Move duplicate alloca.
Thu, May 9, 3:30 AM · efl
Hermet accepted D8869: ector_software_rasterizer : Move duplicate alloca.
Thu, May 9, 3:29 AM · efl

Wed, May 8

Hermet accepted D8846: evas/scale_sample: deduplicate masking code.
Wed, May 8, 7:19 PM · efl: rendering
Hermet requested changes to D8852: evas: enable setting any object as a clipper.

See a comment.

Wed, May 8, 7:13 PM · efl
Hermet requested changes to D8846: evas/scale_sample: deduplicate masking code.
Wed, May 8, 7:09 PM · efl: rendering
Hermet requested changes to D8841: evas/render: clamp mask surface size to clipper size.

Please check comment.

Wed, May 8, 7:08 PM · efl: rendering
Hermet added a comment to D8757: embryo_cc: Fix longjmp clobbering warning..
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?

Wed, May 8, 6:52 PM · efl
Hermet requested changes to D8757: embryo_cc: Fix longjmp clobbering warning..

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

Wed, May 8, 6:50 PM · efl
Hermet added a comment to D8857: ector_software_rasterizer: Remove alloca function..

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?

Wed, May 8, 1:38 AM · efl
Hermet added inline comments to D8857: ector_software_rasterizer: Remove alloca function..
Wed, May 8, 1:37 AM · efl
Hermet requested changes to D8857: ector_software_rasterizer: Remove alloca function..

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

Wed, May 8, 1:28 AM · efl
Hermet closed D8718: efl_ui_animation_view : Change transit facade sequence..
Wed, May 8, 1:05 AM · efl
Hermet closed D8855: ector_software_rasterizer: Support gradient mask blending.
Wed, May 8, 12:58 AM · efl
Hermet accepted D8855: ector_software_rasterizer: Support gradient mask blending.
Wed, May 8, 12:56 AM · efl

Mon, May 6

Hermet added a comment to D8788: evas png: apply interpolation when scale down image loading..

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

Mon, May 6, 11:46 PM · efl

Thu, May 2

Hermet closed D8516: evas_object_image: save EVAS_IMAGE_CONTENT_HINT_DYNAMIC image.
Thu, May 2, 4:58 AM · efl
Hermet requested changes to D7344: evas map: calc map geometry when it is out of screen.

hmm if map object is hidden state?

Thu, May 2, 4:58 AM · efl
Hermet accepted D8516: evas_object_image: save EVAS_IMAGE_CONTENT_HINT_DYNAMIC image.
Thu, May 2, 4:49 AM · efl
Hermet reopened D8788: evas png: apply interpolation when scale down image loading..
Thu, May 2, 4:19 AM · efl
Hermet closed D8788: evas png: apply interpolation when scale down image loading..
Thu, May 2, 2:40 AM · efl
Hermet updated the diff for D8788: evas png: apply interpolation when scale down image loading..

added example.

Thu, May 2, 1:02 AM · efl

Wed, May 1

Hermet added a comment to D8788: evas png: apply interpolation when scale down image loading..

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

Wed, May 1, 10:08 PM · efl

Tue, Apr 30

Hermet added reviewers for D8788: evas png: apply interpolation when scale down image loading.: kimcinoo, jsuya.
Tue, Apr 30, 4:08 AM · efl
Hermet updated the summary of D8788: evas png: apply interpolation when scale down image loading..
Tue, Apr 30, 4:07 AM · efl
Hermet added reviewers for D8788: evas png: apply interpolation when scale down image loading.: cedric, raster, committers.
Tue, Apr 30, 4:01 AM · efl
Hermet updated the diff for D8788: evas png: apply interpolation when scale down image loading..

update code.

Tue, Apr 30, 4:00 AM · efl
Hermet requested review of D8788: evas png: apply interpolation when scale down image loading..
Tue, Apr 30, 3:55 AM · efl

Fri, Apr 26

Hermet accepted D8718: efl_ui_animation_view : Change transit facade sequence..
Fri, Apr 26, 1:47 AM · efl
Hermet closed D8716: efl_ui_animation_view: Fix current frame calc..
Fri, Apr 26, 1:45 AM · efl
Hermet accepted D8716: efl_ui_animation_view: Fix current frame calc..
Fri, Apr 26, 1:43 AM · efl
Hermet closed D8715: efl_ui_animation_view: Update callback is called only actual change time..
Fri, Apr 26, 1:42 AM · efl
Hermet accepted D8715: efl_ui_animation_view: Update callback is called only actual change time..
Fri, Apr 26, 1:41 AM · efl

Thu, Apr 25

Hermet closed D8698: evas_events: fix grab count does not become 0 with proxy object..
Thu, Apr 25, 9:26 PM · efl
Hermet accepted D8698: evas_events: fix grab count does not become 0 with proxy object..
Thu, Apr 25, 9:23 PM · efl
Hermet added a comment to D8698: evas_events: fix grab count does not become 0 with proxy object..

looks good to go, leave verify to zmike.

Thu, Apr 25, 9:20 PM · efl
Hermet closed D8709: vg_common_json: Support mask with matte case..
Thu, Apr 25, 6:52 PM · efl
Hermet accepted D8709: vg_common_json: Support mask with matte case..
Thu, Apr 25, 6:45 PM · efl
Hermet requested changes to D8709: vg_common_json: Support mask with matte case..

please consider code consistency.

Thu, Apr 25, 4:06 AM · efl
Hermet closed D8712: ecore_evas wayland: fix a build break..
Thu, Apr 25, 2:56 AM · efl
Hermet requested review of D8712: ecore_evas wayland: fix a build break..
Thu, Apr 25, 2:56 AM · efl

Mon, Apr 22

Hermet closed D8674: efl_ui_animation_view: Fix cmake build error.
Mon, Apr 22, 5:42 PM · efl
Hermet accepted D8674: efl_ui_animation_view: Fix cmake build error.
Mon, Apr 22, 5:42 PM · efl

Apr 18 2019

Hermet closed D8663: vg_common_svg : Implement gradientTransform property of linearGradient.
Apr 18 2019, 11:07 PM · efl
Hermet closed D8662: vg_common_svg: Prevent duplicate operations for percentage value.
Apr 18 2019, 10:52 PM · efl
Hermet accepted D8662: vg_common_svg: Prevent duplicate operations for percentage value.
Apr 18 2019, 9:55 PM · efl
Hermet requested changes to D8662: vg_common_svg: Prevent duplicate operations for percentage value.

Please check a comment.

Apr 18 2019, 8:48 PM · efl
Hermet closed D8552: evas gl: move to floating point coordinate system..
Apr 18 2019, 4:11 AM · efl
Hermet closed D8563: canvas map: remove the workaround code. .
Apr 18 2019, 3:22 AM · efl
Hermet added a comment to D8619: tests: add api coverage for evas image.

This must be merged when the fix is merged.

Apr 18 2019, 3:20 AM · efl
Hermet planned changes to D8552: evas gl: move to floating point coordinate system..
Apr 18 2019, 12:52 AM · efl
Hermet added a comment to D8552: evas gl: move to floating point coordinate system..

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

Apr 18 2019, 12:51 AM · efl

Apr 17 2019

Hermet updated the diff for D8552: evas gl: move to floating point coordinate system..

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

Apr 17 2019, 11:43 PM · efl
Hermet added a comment to D8552: evas gl: move to floating point coordinate system..

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

Apr 17 2019, 10:31 PM · efl
Hermet added a comment to D8552: evas gl: move to floating point coordinate system..

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.
Apr 17 2019, 9:51 PM · efl
Hermet closed D8507: vg_json: Set multiple mask from json.
Apr 17 2019, 6:23 PM · efl
Hermet accepted D8507: vg_json: Set multiple mask from json.
Apr 17 2019, 6:21 PM · efl
Hermet requested changes to D8595: efl_gfx_gradient: Add Efl.Gfx.Gradient.Units.set/get interface.

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

Apr 17 2019, 6:18 PM · efl
Hermet requested changes to D8507: vg_json: Set multiple mask from json.

Please check comments.

Apr 17 2019, 6:08 PM · efl
Hermet closed D8619: tests: add api coverage for evas image.
Apr 17 2019, 5:59 PM · efl
Hermet accepted D8619: tests: add api coverage for evas image.
Apr 17 2019, 5:58 PM · efl
Hermet added a comment to D8552: evas gl: move to floating point coordinate system..

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.

Apr 17 2019, 1:17 AM · efl

Apr 11 2019

Hermet requested changes to D8507: vg_json: Set multiple mask from json.

Please check comments.

Apr 11 2019, 6:16 PM · efl
Hermet closed D8517: efl_canvas_vg_container : Support mask tree for multiple mask..
Apr 11 2019, 3:23 AM · efl
Hermet accepted D8517: efl_canvas_vg_container : Support mask tree for multiple mask..
Apr 11 2019, 3:19 AM · efl