Cedric wrote:
> On Thu, Feb 26, 2015 at 11:31 PM, jose_...@juno.com <jose_...@juno.com> wrote:
>
>>> On Thu, Feb 26, 2015 at 9:50 PM, jose_...@juno.com <jose_...@juno.com>
>>> wrote:
>>>
>>>> Hey Cedric,
>>>>
>>>> I have a question for you... :)
>>>>
>>>> What are you thinking of doing with the current evas rect, line, and
>>>> polygon objects?
>>>>
>>> I am considering the idea of introducing an Evas_Object_Shape, or
>>> something close to that, and make those 3 objects just reuse that one
>>> with some inheritance and the Ector backend (When Ector will provide a
>>> proper GL backend and be fast enough to replace them of course).
>>>
>> Ok, that seems reasonable. But there are a few things to consider...
>> If you do that, then why not also introduce the rest of the standard shape
>> related objs like polyline, ellipse, circle, path? And where will the
>> fill/stroke-paint
>> properties of shapes come from.. restrict to colors only?
>>
>
> So this is really not defined yet and I am still trying to figure out
> how I will implement that. Currently, the first issue is do we want to
> have an Eo object for Line and Poly. I see no benefit for it.
> Rectangle have a benefit has we can have a custom cutout logic. So I
> could implement Line and Poly just as a set of helper function on top
> of a Shape object.
> Also in my branch I have already started adding a set of simple
> helper (mostly following what the SVG specification says) for
> rectangle with rounded corner and circle. I kind of plan to expand
> that set of helper that generate path over time. This helper will work
> thanks to Eo on both Evas_VG_Shape, Ector_Renderer_Shape and an
> hypothetical Evas_Object_Shape. That should not be a big deal.
>
Right. So, here's the thing - If you add support to the evas line,
rect, polygon objs
for the shape properties like stroke-width, dash/dot, etc... then the
only reasonable
way to do this is for them to internally 'have' a path which you use to
implement them.
i.e. it's the path that supports and implements those aspects and
each particular
shape object that uses a path then also supports those things as
appropriate. That's
what enesim does for example.
So, once you have that then you might as well add the other standard
shape objects..
since the work is basically done. You can still have fast paths for
implementing
some things - like for example if a rect is 'simple' (pixel-aligned, no
stroking, etc)
then you don't have to do a path rasterization, same for say maybe
horz/vert lines
of stroke-width one, no dashing, etc.
So technically, it's a trivial matter to add these extra objs once
you've done
the existing ones as noted. Now, is it worth it? Yes, if it's worth
doing for the
current ones.. So it really boils down to if it's worth making the
current ones fully
shape supporting. It might also see more actual use of these evas objects in
more complex ui+gfx situations, like say graphs/charts.
> For stroke and fill paint source, I am considering allowing the
> source to be any Evas_Object like we do for proxy. The main issue is
> that we don't provide an Evas_Object_Gradient this day anymore, so it
> kind of limit the usefulness of it. That's still something I don't
> really know (I guess I could reintroduce an Evas_Object_Gradient as I
> would have the necessary code in Ector, but not so sure about it).
>
>
Remember years ago I told you that one day you'd have to re-visit
all this stuff... :)
Allowing them to be any evas object is consistent with what enesim
does as well,
but then yes you'd want to have grad objs again. Or, you could just
restrict them to be
colors and grads, where the grads are not evas objs but rather just
something like
a specific 'shape-paint-grad' property, or an ector renderer, or an eina
gradient def?
Note btw that if you support 'masking', then masking an evas object
by a shape
object is similar to painting the shape object with the masked one
(stroke-painting
for stroke-only objs like lines, polylines, and fill-painting for fill
supporting ones).
>> Evas object resizing would also need to be done consistently on these,
>> last I recall it was somewhat inconsistent on the line and poly...
>>
>
> I think we trigger an ERR if you do a resize on a poly this day. Line
> is I think defined as a resize of both end point. But sure that would
> have to be taken care of.
>
If each shape object keeps its initial defining data (vertices or
whatnot) then
it's fairly easy to 're-size' (and move), just scale the original data
to the requested
size divided by its original size and move to the existing top-left
position.
There some details though related to stroking, as that can increase
the extents..
just stuff that needs to be dealt with.
But yes, I'd say move/re-size needs to be done consistently and
meaningfully
for the shape objs.
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
