Hey,

Thank you!

Have you already tried it out with ThorVG or VG-Lite (or other GPU)?

As these files uses float please add an #if LV_USE_VECTOR to let the user make LVGL work without float.

Hey,

Thank you!

Have you already tried it out with ThorVG or VG-Lite (or other GPU)?

Not yet, this is only the task distribution part and no task handler has been implemented so far.

Updated:

1. Changed all API names to lv_vpath_*
2. Added lv_vpath_submit to daisy chain draw tasks before submitting them. GPU will benefit from batch processing. A lv_vpath_draw_oneshot() is provided for simplified operation.
3. Enriched matrix helpers with pseudo 3d transformations
4. Added enum lv_vpath_blend_t for Porter-Duff blend operators

Please use vector_path instead of vpath. From v9 abbreviations should be avoided for the sake of clarity.

Please use vector_path instead of vpath. From v9 abbreviations should be avoided for the sake of clarity.

I think "lv_vector_path_" is too long as a prefix, how about “lvg_" ？ @kisvegabor

I looked into the API again I'm a little bit puzzled by

• lv_vpath_draw
• lv_vpath_clear
• lv_vpath_submit
• lv_vpath_draw_oneshot
• lv_vpath_task_create

have the same prefix as lv_vpath_quad_to, but they operate on a task list and not a vector path.

What about something like this:

/*Same as `lv_vpath_t`
 *"vector_path" is not prefix but the whole name here*/
lv_vector_path_t * lv_vector_path_create(void);
void lv_vector_path_quad_to(lv_vector_path_t * path, lv_fpoint_t p1, lv_fpoint_t p2);

/*Same as `lv_vpath_dsc_t`
 *lv_vector_draw_dsc_t ) has   `lv_vector_path_t * path`  and  `lv_vector_draw_dsc_t * next` fields*/
void lv_vector_draw_dsc_init(lv_vector_draw_dsc_t * dsc); 
dsc.path = some_path;
dsc.fill_dsc.color = lv_color_hex(0xffaa00);
dsc.next = &another_dsc;

/*Start drawing*/
void lv_vector_draw(struct _lv_layer_t * layer, lv_vector_draw_dsc_t * dsc);

I looked into the API again I'm a little bit puzzled by

• lv_vpath_draw
• lv_vpath_clear
• lv_vpath_submit
• lv_vpath_draw_oneshot
• lv_vpath_task_create

have the same prefix as lv_vpath_quad_to, but they operate on a task list and not a vector path.

What about something like this:

/*Same as `lv_vpath_t`
 *"vector_path" is not prefix but the whole name here*/
lv_vector_path_t * lv_vector_path_create(void);
void lv_vector_path_quad_to(lv_vector_path_t * path, lv_fpoint_t p1, lv_fpoint_t p2);

/*Same as `lv_vpath_dsc_t`
 *lv_vector_draw_dsc_t ) has   `lv_vector_path_t * path`  and  `lv_vector_draw_dsc_t * next` fields*/
void lv_vector_draw_dsc_init(lv_vector_draw_dsc_t * dsc); 
dsc.path = some_path;
dsc.fill_dsc.color = lv_color_hex(0xffaa00);
dsc.next = &another_dsc;

/*Start drawing*/
void lv_vector_draw(struct _lv_layer_t * layer, lv_vector_draw_dsc_t * dsc);

I think this way is not easy to use. The draw_dsc list should be implements under a contxt and should not be maintained by the caller, which is easy cause to errors.
for example:

lv_vpath_draw_context_t* ctx = lv_vpath_draw_context_create(layer);

/*Start drawing*/
lv_vector_path_set_fill_color(ctx, lv_color_hex(0xffaa00));
lv_vector_draw(ctx,  some_path);

lv_vector_path_set_stroke_color(ctx, lv_color_hex(0xffbbaa));
lv_vector_draw(ctx,  another_path);

lv_vector_commit(ctx); // submit the draw list here

...
lv_vpath_draw_context_destroy(ctx);

In this way, the caller of the API does not need to worry about drawing the list and can focus on the drawing logic.
What do you think of this way? @kisvegabor

What is the content of lv_vpath_draw_context_t? Is it different from lv_vpath_dsc_t in the PR?

So lv_vector_draw handles the creation of the list, right?

For the sake of consistency with other draw tasks, it'd be great if lv_vector_draw could mean the real drawing (lv_vector_commit in the example) and lv_vector_commit would be lv_vector_add or something like that.

What is the content of lv_vpath_draw_context_t? Is it different from lv_vpath_dsc_t in the PR?

So lv_vector_draw handles the creation of the list, right?

For the sake of consistency with other draw tasks, it'd be great if lv_vector_draw could mean the real drawing (lv_vector_commit in the example) and lv_vector_commit would be lv_vector_add or something like that.

lv_vpath_draw_context_t is used to save and maintain 'draw_list'. When lv_vector_draw is called, a new draw operation will be added to 'draw_list' , When lv_vector_commit is called, a real lvgl draw task will be created for the drawing task, and the 'draw_list' will be traversed in callback to complete the actual drawing. It is similar as a "Recording / Playback" mechanism.
We think this would reduce interruptions to other lvgl widget's drawing.

Refined API naming and added skew functions. There is one more thing from our internal discussion:
Since the parallel rendering architecture is asynchronous, the path content has to be copied when drawing. As such, zero-copying of path cannot be achieved. So it shouldn't be much pain to add an internal representation of path and convert it to vendor-specific format during rendering. It's O(n) anyway. The code will look cleaner and more consistent with parallel rendering framework, benefiting from less conditionally compiled files.

You mean lv_vector_path_t, right? If so, I think we can make the vector library to populate a lv_vector_path_t type. IMO it would be quite consistent as functions like lv_vector_path_move_to are implemented by the vector library anyway as well.

We need some feedback on this pull request.

Now we mark this as "stale" because there was no activity here for 14 days.

Remove the "stale" label or comment else this will be closed in 7 days.

Not stale

We need some feedback on this pull request.

Now we mark this as "stale" because there was no activity here for 14 days.

Remove the "stale" label or comment else this will be closed in 7 days.

Closing in favor of #4691.