Re: [E-devel] Line + width support.
On Tue, 20 May 2008 10:14:48 -0300 "Diego Bitencourt Contezini" <[EMAIL PROTECTED]> babbled: hmm. i'd rather hold here in favor of a much more... expansive set of vgfx support... and nail this kind of thing all in one shot. > We decided to improve the line implementation to speed up the use of > evas-lines in python (our case). Yes, we could just use polygons, but we are > trying to reduce processor usage at this point. > Its faster to draw lines (with lines implementation) directly, specially > dealing with vertical/horizontal/45 deg. lines. > Calculating where points of polygons must be drawn relative to width of line > in python-side is a lost of processing too. > > Being faster, simpler and without breaking any compatibility, I dont know > why Lines should not to have width support. Specially thinking about how > simpler it makes to work with Lines. > Yes, the code may be optimized, but its working fine and fast here. > > Greetings, > > Diego B. Contezini > > On Sun, May 18, 2008 at 11:51 PM, The Rasterman Carsten Haitzler < > [EMAIL PROTECTED]> wrote: > > > On Tue, 13 May 2008 17:20:27 -0300 "Diego Bitencourt Contezini" > > <[EMAIL PROTECTED]> babbled: > > > > any reason you didnt just use polygons? :) > > > > > Hello all. > > > Working with evas+Lines in python, is fast. But if you need a line with > > more > > > then one pixel of width, it gets very slow (in dispositives like N800), > > > because object Line dont have width support, so its needen to use > > Rectangles > > > to make it works. > > > > > > I made a modification to support width in Lines object. It is composed by > > 3 > > > patchs. > > > *First*, in evas/lib/*, it changes internal call to engine line drawer, > > > inserting more one argument to the same function. It is a callback, so, > > no > > > modification is needen in any engine module that dosnt support Lines with > > > more then 1 pixel (they will just draw with only 1 pixel). Has added new > > > functions to deal with width, without breaking any compatibility of other > > > functions. > > > *Second*, in evas/engine/software16 to add support to width. > > > *Third,* in python-evas binding, to add support to use the modifications > > > made in evas. > > > > > > If anyone get any bug or suggest any modification to patch, im a > > listener. > > > > > > Thanks all > > > > > > Diego Bitencourt Contezini > > > > > > > > > -- > > - Codito, ergo sum - "I code, therefore I am" -- > > The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] > > > > > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Line + width support.
Diego wrote: > We decided to improve the line implementation to speed up the use of > evas-lines in python (our case). Yes, we could just use polygons, but we are > trying to reduce processor usage at this point. > Its faster to draw lines (with lines implementation) directly, specially > dealing with vertical/horizontal/45 deg. lines. > Calculating where points of polygons must be drawn relative to width of line > in python-side is a lost of processing too. > > Being faster, simpler and without breaking any compatibility, I dont know > why Lines should not to have width support. Specially thinking about how > simpler it makes to work with Lines. > Yes, the code may be optimized, but its working fine and fast here. > > It may be simpler to have your desired wide lines, but it's not really any faster than using current polygons, nor is it really accurate. But the real issue is simply that this is a terrible way to introduce such abilities in evas - ie. the api (and internals). As I mentioned in an earlier email, one should present this in a more general form so that further stroke/fill aspects can be exposed for not only lines but also rectangles, polygons, and maybe other objects at a later point. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Line + width support.
This patches I sent last mail are the last working, sorry, I forgot to tell. They are with two corrections we've got here in testing. Diego - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Line + width support.
We decided to improve the line implementation to speed up the use of
evas-lines in python (our case). Yes, we could just use polygons, but we are
trying to reduce processor usage at this point.
Its faster to draw lines (with lines implementation) directly, specially
dealing with vertical/horizontal/45 deg. lines.
Calculating where points of polygons must be drawn relative to width of line
in python-side is a lost of processing too.
Being faster, simpler and without breaking any compatibility, I dont know
why Lines should not to have width support. Specially thinking about how
simpler it makes to work with Lines.
Yes, the code may be optimized, but its working fine and fast here.
Greetings,
Diego B. Contezini
On Sun, May 18, 2008 at 11:51 PM, The Rasterman Carsten Haitzler <
[EMAIL PROTECTED]> wrote:
> On Tue, 13 May 2008 17:20:27 -0300 "Diego Bitencourt Contezini"
> <[EMAIL PROTECTED]> babbled:
>
> any reason you didnt just use polygons? :)
>
> > Hello all.
> > Working with evas+Lines in python, is fast. But if you need a line with
> more
> > then one pixel of width, it gets very slow (in dispositives like N800),
> > because object Line dont have width support, so its needen to use
> Rectangles
> > to make it works.
> >
> > I made a modification to support width in Lines object. It is composed by
> 3
> > patchs.
> > *First*, in evas/lib/*, it changes internal call to engine line drawer,
> > inserting more one argument to the same function. It is a callback, so,
> no
> > modification is needen in any engine module that dosnt support Lines with
> > more then 1 pixel (they will just draw with only 1 pixel). Has added new
> > functions to deal with width, without breaking any compatibility of other
> > functions.
> > *Second*, in evas/engine/software16 to add support to width.
> > *Third,* in python-evas binding, to add support to use the modifications
> > made in evas.
> >
> > If anyone get any bug or suggest any modification to patch, im a
> listener.
> >
> > Thanks all
> >
> > Diego Bitencourt Contezini
> >
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
>
>
--- evas-0.9.9.042/src/lib/canvas/evas_object_line.c 2008-05-07 17:22:34.0 -0300
+++ evas-linha/src/lib/canvas/evas_object_line.c 2008-05-20 09:50:03.0 -0300
@@ -18,6 +18,7 @@
} object;
} cache;
Evas_Coord x1, y1, x2, y2;
+ int width;
} cur, prev;
void *engine_data;
@@ -86,7 +87,6 @@
evas_object_inject(obj, e);
return obj;
}
-
/**
* Sets the coordinates of the end points of the given evas line object.
* @param obj The given evas line object.
@@ -143,12 +143,12 @@
obj->cur.geometry.y = min_y;
obj->cur.geometry.w = max_x - min_x + 2.0;
obj->cur.geometry.h = max_y - min_y + 2.0;
- obj->cur.cache.geometry.validity = 0;
o->cur.x1 = x1 - min_x;
o->cur.y1 = y1 - min_y;
o->cur.x2 = x2 - min_x;
o->cur.y2 = y2 - min_y;
o->changed = 1;
+ o->cur.width = 1;
evas_object_change(obj);
evas_object_coords_recalc(obj);
if (obj->layer->evas->events_frozen <= 0)
@@ -171,6 +171,122 @@
}
/**
+ * Sets the coordinates of the end points of the given evas line object with width param.
+ * @param objThe given evas line object.
+ * @param x1 The X coordinate of the first point.
+ * @param y1 The Y coordinate of the first point.
+ * @param x2 The X coordinate of the second point.
+ * @param y2 The Y coordinate of the second point.
+ * @param width The width of the line.
+ * @ingroup Evas_Line_Group
+ */
+EAPI void
+evas_object_line_xyw_set(Evas_Object *obj, Evas_Coord x1, Evas_Coord y1, Evas_Coord x2, Evas_Coord y2, int width)
+{
+ Evas_Object_Line *o;
+ Evas_Coord min_x, max_x, min_y, max_y;
+ int is, was = 0;
+
+ MAGIC_CHECK(obj, Evas_Object, MAGIC_OBJ);
+ return;
+ MAGIC_CHECK_END();
+ o = (Evas_Object_Line *)(obj->object_data);
+ MAGIC_CHECK(o, Evas_Object_Line, MAGIC_OBJ_LINE);
+ return;
+ MAGIC_CHECK_END();
+ if ((x1 == o->cur.x1) && (y1 == o->cur.y1) &&
+ (x2 == o->cur.x2) && (y2 == o->cur.y2)) return;
+
+ if (obj->layer->evas->events_frozen <= 0)
+ {
+ if (!evas_event_passes_through(obj))
+ was = evas_object_is_in_output_rect(obj,
+ obj->layer->evas->pointer.x,
+ obj->layer->evas->pointer.y, 1, 1);
+ }
+
+ if (x1 < x2)
+ {
+ min_x = x1;
+ max_x = x2;
+ }
+ else
+ {
+ min_x = x2;
+ max_x = x1;
+ }
+
+ if (y1 < y2)
+ {
+ min_y = y1;
+ max_y = y2;
+ }
+ else
+ {
+ min_y = y2;
+ max_y = y1;
+ }
+
+ if(width > 1)
+ {
+ int tsum; // type of Sum (x = 0, y = 1)
+ if(x1 == x2)
+ { // vertical line
+ if(y1 == y2)
+ tsum = 1;
+ else
+ tsum = 0;
+ } else if(y1 == y2) // horizontal line
+ tsum = 1;
+ else if((max_x - min_x) > (max_y - min_y)) // dx > dy
+ tsum = 1;
+ else // dx <= dy
+ tsum = 0;
+
+ if(ts
Re: [E-devel] Line + width support.
On Tue, 13 May 2008 17:20:27 -0300 "Diego Bitencourt Contezini" <[EMAIL PROTECTED]> babbled: any reason you didnt just use polygons? :) > Hello all. > Working with evas+Lines in python, is fast. But if you need a line with more > then one pixel of width, it gets very slow (in dispositives like N800), > because object Line dont have width support, so its needen to use Rectangles > to make it works. > > I made a modification to support width in Lines object. It is composed by 3 > patchs. > *First*, in evas/lib/*, it changes internal call to engine line drawer, > inserting more one argument to the same function. It is a callback, so, no > modification is needen in any engine module that dosnt support Lines with > more then 1 pixel (they will just draw with only 1 pixel). Has added new > functions to deal with width, without breaking any compatibility of other > functions. > *Second*, in evas/engine/software16 to add support to width. > *Third,* in python-evas binding, to add support to use the modifications > made in evas. > > If anyone get any bug or suggest any modification to patch, im a listener. > > Thanks all > > Diego Bitencourt Contezini > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Line + width support.
Diego wrote: > Hello all. > Working with evas+Lines in python, is fast. But if you need a line with more > then one pixel of width, it gets very slow (in dispositives like N800), > because object Line dont have width support, so its needen to use Rectangles > to make it works. > > I made a modification to support width in Lines object. It is composed by 3 > patchs. > *First*, in evas/lib/*, it changes internal call to engine line drawer, > inserting more one argument to the same function. It is a callback, so, no > modification is needen in any engine module that dosnt support Lines with > more then 1 pixel (they will just draw with only 1 pixel). Has added new > functions to deal with width, without breaking any compatibility of other > functions. > *Second*, in evas/engine/software16 to add support to width. > *Third,* in python-evas binding, to add support to use the modifications > made in evas. > > If anyone get any bug or suggest any modification to patch, im a listener. > > Thanks all > > Diego Bitencourt Contezini > This may seem like a nice addition to evas.. but it's really not a good way to go about it (nor are the particular api functions added or internal engine functions particularly desirable). Evas needs better vgfx support overall, and that means that certain kinds of objects like lines, rectangles, polygons,... should support stroke and/or fill properties - including such things as stroke weight(s) as you want here for lines. To do this correctly, and satisfactorily, needs a lot of work - something like this right now, while well-intentioned, is really not advisable.. This is not a trivial gfx aspect to support well. As far as an api goes, one should be able to set stroke and fill colors and/or textures on an object, wether an object should be stroked and/or filled (if possible), and various stroke properties such as weight(s), cap/join styles, etc. Of course one could cut down the set of things one may want evas to support - it's not necessary to have full support for everything. If you're interested in really looking into adding such vgfx capabilities to evas you could check out various polygon rasterization implementations and polygon-stroking approaches. Maybe consult with Jorge (turran) as he's been doing some work on aa polygon rasterization. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Line + width support.
Hi Diego, Forget about the API break, my mistake. As soon as I have time will take a look more deeply and test some benchmarks. BR, Adriano On Fri, May 16, 2008 at 4:40 PM, Adriano Rezende <[EMAIL PROTECTED]> wrote: > On Tue, May 13, 2008 at 5:51 PM, Gustavo Sverzut Barbieri > <[EMAIL PROTECTED]> wrote: >> On Tue, May 13, 2008 at 5:20 PM, Diego Bitencourt Contezini >> <[EMAIL PROTECTED]> wrote: >>> Hello all. >>> Working with evas+Lines in python, is fast. But if you need a line with >>> more >>> then one pixel of width, it gets very slow (in dispositives like N800), >>> because object Line dont have width support, so its needen to use >>> Rectangles >>> to make it works. >>> >>> I made a modification to support width in Lines object. It is composed by 3 >>> patchs. >>> *First*, in evas/lib/*, it changes internal call to engine line drawer, >>> inserting more one argument to the same function. It is a callback, so, no >>> modification is needen in any engine module that dosnt support Lines with >>> more then 1 pixel (they will just draw with only 1 pixel). Has added new >>> functions to deal with width, without breaking any compatibility of other >>> functions. >>> *Second*, in evas/engine/software16 to add support to width. >>> *Third,* in python-evas binding, to add support to use the modifications >>> made in evas. >>> >>> If anyone get any bug or suggest any modification to patch, im a listener. >> >> Hi, >> >> I have no time to look at this now, but when we required lines with > >> 1px width we used polygons with great success. >> >> Actually, I guess it's difficult to see single lines being used >> separated, often we use connected lines, in this case it would be >> great to be able to choose the caps/join to be used... using polygons >> users can implement this. >> >> Of course creating the polygons are bit hard, so having this ready in >> Evas would help a lot :-) >> >> -- >> Gustavo Sverzut Barbieri >> http://profusion.mobi embedded systems >> -- >> MSN: [EMAIL PROTECTED] >> Skype: gsbarbieri >> Mobile: +55 (19) 9225-2202 > > Hi Diego, > > We use polygons to trace routes and other things too. > I suggest you to send some benchmarks to the list showing the benefits > of this patch with some use cases. With this in hand is better to > apply your patch. Gustavo is one of the most indicated people to judge > and apply your patch due the fact it's used with software 16 engine. > I didn't have time to test it yet but one thing that I noted is that > you are changing the line_draw signature and this will break the API > breaking some applications in consequence. So it would be better to > create another method that draw a line with specified width. > > > Adriano Rezende > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Line + width support.
On Tue, May 13, 2008 at 5:51 PM, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote: > On Tue, May 13, 2008 at 5:20 PM, Diego Bitencourt Contezini > <[EMAIL PROTECTED]> wrote: >> Hello all. >> Working with evas+Lines in python, is fast. But if you need a line with more >> then one pixel of width, it gets very slow (in dispositives like N800), >> because object Line dont have width support, so its needen to use Rectangles >> to make it works. >> >> I made a modification to support width in Lines object. It is composed by 3 >> patchs. >> *First*, in evas/lib/*, it changes internal call to engine line drawer, >> inserting more one argument to the same function. It is a callback, so, no >> modification is needen in any engine module that dosnt support Lines with >> more then 1 pixel (they will just draw with only 1 pixel). Has added new >> functions to deal with width, without breaking any compatibility of other >> functions. >> *Second*, in evas/engine/software16 to add support to width. >> *Third,* in python-evas binding, to add support to use the modifications >> made in evas. >> >> If anyone get any bug or suggest any modification to patch, im a listener. > > Hi, > > I have no time to look at this now, but when we required lines with > > 1px width we used polygons with great success. > > Actually, I guess it's difficult to see single lines being used > separated, often we use connected lines, in this case it would be > great to be able to choose the caps/join to be used... using polygons > users can implement this. > > Of course creating the polygons are bit hard, so having this ready in > Evas would help a lot :-) > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -- > MSN: [EMAIL PROTECTED] > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 Hi Diego, We use polygons to trace routes and other things too. I suggest you to send some benchmarks to the list showing the benefits of this patch with some use cases. With this in hand is better to apply your patch. Gustavo is one of the most indicated people to judge and apply your patch due the fact it's used with software 16 engine. I didn't have time to test it yet but one thing that I noted is that you are changing the line_draw signature and this will break the API breaking some applications in consequence. So it would be better to create another method that draw a line with specified width. Adriano Rezende - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Line + width support.
On Tue, May 13, 2008 at 5:20 PM, Diego Bitencourt Contezini <[EMAIL PROTECTED]> wrote: > Hello all. > Working with evas+Lines in python, is fast. But if you need a line with more > then one pixel of width, it gets very slow (in dispositives like N800), > because object Line dont have width support, so its needen to use Rectangles > to make it works. > > I made a modification to support width in Lines object. It is composed by 3 > patchs. > *First*, in evas/lib/*, it changes internal call to engine line drawer, > inserting more one argument to the same function. It is a callback, so, no > modification is needen in any engine module that dosnt support Lines with > more then 1 pixel (they will just draw with only 1 pixel). Has added new > functions to deal with width, without breaking any compatibility of other > functions. > *Second*, in evas/engine/software16 to add support to width. > *Third,* in python-evas binding, to add support to use the modifications > made in evas. > > If anyone get any bug or suggest any modification to patch, im a listener. Hi, I have no time to look at this now, but when we required lines with > 1px width we used polygons with great success. Actually, I guess it's difficult to see single lines being used separated, often we use connected lines, in this case it would be great to be able to choose the caps/join to be used... using polygons users can implement this. Of course creating the polygons are bit hard, so having this ready in Evas would help a lot :-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Line + width support.
Hello all.
Working with evas+Lines in python, is fast. But if you need a line with more
then one pixel of width, it gets very slow (in dispositives like N800),
because object Line dont have width support, so its needen to use Rectangles
to make it works.
I made a modification to support width in Lines object. It is composed by 3
patchs.
*First*, in evas/lib/*, it changes internal call to engine line drawer,
inserting more one argument to the same function. It is a callback, so, no
modification is needen in any engine module that dosnt support Lines with
more then 1 pixel (they will just draw with only 1 pixel). Has added new
functions to deal with width, without breaking any compatibility of other
functions.
*Second*, in evas/engine/software16 to add support to width.
*Third,* in python-evas binding, to add support to use the modifications
made in evas.
If anyone get any bug or suggest any modification to patch, im a listener.
Thanks all
Diego Bitencourt Contezini
diff -Naur evas-0.9.9.042/src/modules/engines/software_16/evas_engine.c evas-linha/src/modules/engines/software_16/evas_engine.c
--- evas-0.9.9.042/src/modules/engines/software_16/evas_engine.c 2008-05-07 17:22:35.0 -0300
+++ evas-linha/src/modules/engines/software_16/evas_engine.c 2008-05-13 14:35:03.0 -0300
@@ -149,9 +149,9 @@
}
static void
-eng_line_draw(void *data, void *context, void *surface, int x1, int y1, int x2, int y2)
+eng_line_draw(void *data, void *context, void *surface, int x1, int y1, int x2, int y2, int width)
{
- soft16_line_draw(surface, context, x1, y1, x2, y2);
+ soft16_line_draw(surface, context, x1, y1, x2, y2, width);
}
static void *
diff -Naur evas-0.9.9.042/src/modules/engines/software_16/evas_soft16.h evas-linha/src/modules/engines/software_16/evas_soft16.h
--- evas-0.9.9.042/src/modules/engines/software_16/evas_soft16.h 2008-05-07 17:22:35.0 -0300
+++ evas-linha/src/modules/engines/software_16/evas_soft16.h 2008-05-13 14:35:03.0 -0300
@@ -139,7 +139,7 @@
* Line (evas_soft16_line.c)
*/
void
-soft16_line_draw(Soft16_Image *dst, RGBA_Draw_Context *dc, int x0, int y0, int x1, int y1);
+soft16_line_draw(Soft16_Image *dst, RGBA_Draw_Context *dc, int x0, int y0, int x1, int y1, int width);
/**
diff -Naur evas-0.9.9.042/src/modules/engines/software_16/evas_soft16_line.c evas-linha/src/modules/engines/software_16/evas_soft16_line.c
--- evas-0.9.9.042/src/modules/engines/software_16/evas_soft16_line.c 2008-05-07 17:22:35.0 -0300
+++ evas-linha/src/modules/engines/software_16/evas_soft16_line.c 2008-05-13 14:35:03.0 -0300
@@ -71,8 +71,8 @@
dst_itr = dst->pixels + (dst->stride * y) + x;
alpha = A_VAL(&dc->col.col) >> 3;
rgb565 = RGB_565_FROM_COMPONENTS(R_VAL(&dc->col.col),
-G_VAL(&dc->col.col),
-B_VAL(&dc->col.col));
+ G_VAL(&dc->col.col),
+ B_VAL(&dc->col.col));
if (alpha == 31)
_soft16_pt_fill_solid_solid(dst_itr, rgb565);
@@ -87,52 +87,62 @@
}
static void
-_soft16_line_horiz(Soft16_Image *dst, RGBA_Draw_Context *dc, int x0, int x1, int y)
+_soft16_line_horiz(Soft16_Image *dst, RGBA_Draw_Context *dc, int x0, int x1, int y, int width)
{
DATA16 rgb565, *dst_itr;
DATA8 alpha;
+ int dx;
int w;
-
- if (!_is_y_inside_clip(y, dc->clip))
- return;
-
if (x0 < dc->clip.x)
x0 = dc->clip.x;
if (x1 >= dc->clip.x + dc->clip.w)
x1 = dc->clip.x + dc->clip.w - 1;
- w = x1 - x0;
- if (w < 1)
+ dx = x1 - x0;
+ if (dx < 1)
return;
- dst_itr = dst->pixels + (dst->stride * y) + x0;
- alpha = A_VAL(&dc->col.col) >> 3;
- rgb565 = RGB_565_FROM_COMPONENTS(R_VAL(&dc->col.col),
-G_VAL(&dc->col.col),
-B_VAL(&dc->col.col));
+ dx++;
- if (alpha == 31)
- _soft16_scanline_fill_solid_solid(dst_itr, w, rgb565);
- else if (alpha > 0)
+ for(w = 0; w < width; w++)
{
- DATA32 rgb565_unpack;
+ int ay;
+ if(w%2) // not pair
+ ay = y+(w/2) + 1;
+ else // pair
+ ay = y-(w/2);
+ if (!_is_y_inside_clip(ay, dc->clip))
+ continue;
+
+ dst_itr = dst->pixels + (dst->stride * ay) + x0;
+ alpha = A_VAL(&dc->col.col) >> 3;
+ rgb565 = RGB_565_FROM_COMPONENTS(R_VAL(&dc->col.col),
+ G_VAL(&dc->col.col),
+ B_VAL(&dc->col.col));
+
+ if (alpha == 31)
+ _soft16_scanline_fill_solid_solid(dst_itr, dx, rgb565);
+ else if (alpha > 0)
+ {
+ DATA32 rgb565_unpack;
- rgb565_unpack = RGB_565_UNPACK(rgb565);
- alpha++;
- _soft16_scanline_fill_transp_solid(dst_itr, w, rgb565_unpack, alpha);
+ rgb565_unpack = RGB_565_UNPACK(rgb565);
+ alpha++;
+ _soft16_scanline_fill_transp_solid(dst_itr, dx, rgb565_unpack, alpha);
+ }
}
+ return;
}
static void
-_soft16_line_vert(Soft16_Image *dst, RGBA_Draw_Context *dc, int x, int y0, int y1)
+_soft16_line_vert(Soft16_Image *dst, RGBA_Draw_Context *dc, int x, int y0, int y1, int width)
{
DATA16 rgb565, *dst_itr;
DATA8 alpha;
- int h;
-
- if (!_is_x_inside_clip(x, dc->clip))
