The ellipse code is total shit, but at least now it does what it is supposed
to.
Could someone with the ability do a release at some point? Lots of users
have reported problems with bug.
SVN revision: 6164
draw_pixel had an inverted test for clipping and so was always calling the
wrong function.
Will this fix ever see the light of day? Who knows?! :)
SVN revision: 6163
uses Tom's macro (__imlib_draw_set_point and *_clipped) so it's faster and it
handles clipping, too.
Btw Tom, I choosed not to change the name of the wrap function so that :
1) I don't have to change it in doc/index.html ;)
2) I think it's a little more in line with Imlib_image_draw_line ...
Lightman
SVN revision: 5305
it installs freetype 2.0.3 , and so freetype.h (for ftype1) is under
/usr/include/freetype1/freetype/freetype.h .
As to not have plp complaining imlib2 can't find freetype under rh 7.2 , I patched
configure to work with roswell.
Lightman
SVN revision: 5304
In fact, I wrote it just for the Bezier drawing function, but I thought it
could be useful in other cases too.
Have fun, Lightman :)
SVN revision: 5302
set_cliprect(0,0,0,0) is supposed to disable clipping, but the calls in
api.c subtract one from maxx and maxy, so that breaks some of the logic that
checked for the need to clip. This is a temporary fix, but it does work.
That "whether to clip or not" logic needs a rewrite, but I'm real tired.
SVN revision: 5275
I have tested:
feh test:image.jpg WORKS
imlib2_view e/data/icons/image/png.db:/icon/clicked WORKS
I have tested saving with geist too and that works.
The patch is bigger than it would have been because I had to revert some of
raster's attempt. There is more debris left over (unused functions and
params etc) but I won't clean all that out until people have checked out
this and are happy.
I might make something like imlib_get_real_filename available in the public
API. So that apps (like feh) that use stat() that do their own error checking
can also do the right thing, but this is a separate issue and not totally
necessary.
SVN revision: 5122
now we escpae literal colons with double colons. it's documented too. (this
was easier to do as i also have to do it for ssving files and you cant stat
to see if a file exisit fi you havent saved it yet)
SVN revision: 5080
* fix build so loaders build if u have no imlib2 installed
* fix requires and buildrequires in spec file for freetype & edb to be correct
SVN revision: 4105
Polygons are now filled with antialiasing, if context_antialias is set.
So are ellipses.
I fixed some clipping bugs.
There is a bug with the AA span though, it's just a little one, but I'm too
tired to find it now. You will see it if you look closely at the top of the
filled ellipse in test/imlib2, using xmag or something.
I'll fix that tomorrow, speed things up a bit, and hopefully implement AA
drawing for ellipse outlines. Oh, I'll unroll some more loops too.
raster: your last commit broke the two test apps. a segv in _RGBA_init()
somewhere, I know it's not my new code, as I tried a fresh checkout and it
did the same thing. I don't have time to check it out tonight though.
SVN revision: 3498
Implemented a span-list clipper.
Inlined the drawing code for span().
Cleaned up and speeded up a couple of drawing funcs.
Polygons filled much faster now. More to do though.
SVN revision: 3480
revamp rpm packages completely. split loaders into their own packages
(more logical units). main imlib2 requires the jpeg, png and db laoders
at a minimum
SVN revision: 3417
Added the function:
unsigned char imlib_polygon_contains_point(ImlibPolygon poly, int x,
int y);
Tells you if a point lies in a polygon. Handy for apps that might want to
test for "selection" of a polygon shape or something...
SVN revision: 3355
clipping rect, but highly suboptimally (I'm not doing proper polygon
clipping here yet, just clipping slowly on each point drawn - really nasty).
There are probably some rounding errors in here. I need to work more on
this, but I have *so* little time for the next few weeks.
Please don't kill me for this code. It's not finished, but I'm about to move
house, and I have to get something working before I pack my PC away.
SVN revision: 3303
Hard to come up with a nice API for this, but here's what I have:
ImlibPolygon imlib_polygon_new(int type);
void imlib_polygon_free(ImlibPolygon poly);
void imlib_polygon_add_point(ImlibPolygon poly, int x, int y);
void imlib_image_draw_polygon(ImlibPolygon poly);
Clipping works with these, as demonstrated by test/imlib2
The type paramter may be: POLY_OPEN, POLY_CLOSED or POLY_FILLED (last one
not implemented yet).
I was wondering if draw_polygon should genererate updates, like draw_line.
Thoughts?
SVN revision: 3279
Removed all the _clipped functions.
Added imlib_context_set_cliprect(int x, int y, int w, int h) and a
corresponding _get_cliprect.
Set width to 0 to disable clipping (default).
Just use the normal _draw_ functions and it'll do the Right thing.
SVN revision: 3278
Sometimes it's handy to work out where your line was/would be drawn.
int
imlib_clip_line(int x0, int y0, int x1, int y1, int xmin, int xmax, int ymin,
int ymax, int *clip_x0, int *clip_y0, int *clip_x1,
int *clip_y1);
SVN revision: 3277
void
imlib_image_draw_rectangle_clipped(int x, int y, int width, int height,
int clip_xmin, int clip_xmax, int clip_ymin,
int clip_ymax);
Works well. If you make install then cd test, make, ./imlib2, you'll see the
demo/test of the clipping code.
Next up: draw_polygon and draw_polygon_clipped.
Then (eeek) fill_polygon, fill_polygon_clipped, and some clipping for image
blending (fun).
SVN revision: 3276
Same as _draw_line but with extra parameters for the clipping region.
Tested and seems to work well. Will check further tomorrow when I convert
geist to use this instead of doing it internally.
Imlib_Updates
imlib_image_draw_line_clipped(int x1, int y1, int x2, int y2,
int clip_xmin, int clip_xmax, int clip_ymin,
int clip_ymax, char make_updates);
SVN revision: 3273
Reversed that change, as it caused segfaults in free().
I can't grok this code, so I'll leave it to raster.
Basically, if my code calls imlib_free_image_and_decache(), it doesn't free
the image, and it leaks.
The fix I applied made sure _Imlib_ConsumeImage was called, but this caused
a segfault.
*baffle
SVN revision: 3239
right fix here. Basically, the imlib_free_image_and_decache() call in api.c
sets the flag F_INVALID then calls the internal __ImlibFreeImage(), this
checks if the flag F_UNCACHEABLE is set, and only frees it if so.
So the image never got free()d. I have changed the
imlib_free_image_and_decache() to set the F_UNCACHEABLE flag *as well* as
F_INVALID. I hope that's the correct fix. raster?
SVN revision: 3238
(KainX)
It's generally a good idea to increment the reference count when you
implement reference counting. This should fix the mysterious problems
people have been having with Imlib2 stealing pixmaps out from under
Eterm.
SVN revision: 2916
play with soon - want to get the stuff correct before I commit some more
stuff. dox is the start of dox2 the document viewer based on imlib2. Designed
so that the style of the docs is seperate from the contents. Will evolve
rapdily over the next week.
SVN revision: 2716
variable to another filter as willem requested the other day.
eg.
filter( var=anotherfilter( var=13,var=30 ), var=blum );
youcan have as manylevels of filters as you want.
* parser should be quicker, no need to add "NULL" to the end of a
imlib_apply_filter() command.
* some more funky filters should be added soon, at 4.45am i decided to leave
that job till t/m.
SVN revision: 2686
one, this means the bump_mapped pr0n will now render a coupla degree's faster
(gilbertt this is for you, and those pictures of pabs' mom)
* Update Imlib2.h and api.c to reflect changes
ps. on the road to the next gen script interpreter
SVN revision: 2677
(gilbertt)
Okay, an ImlibProgressFunction now return int, not void. The idea of this is
so that a progressive load may be aborted midway, simply by returning 0 from
the progress callback. There are a number of reasons for wanting this.
This is a slight breakage to people currently using progressive loading -
you'll have to change your definition to int, and return 1 to get normal
behaviour again. As far as I know, only feh and imlib2_view uses progressive
loading, and I'll sort those two out. To anyone else, sorry, but it's not
released yet, what did you expect? ;-)
Notice. I haven't changed the loaders yet, so returning 0 won't do squat
until tomorrow, when I change them all. What they will do is clean up and
return what they've got so far. If anyone who wrote a loader wants to do
their own, cool, it'll save me learning the api of every damn image lib ;-)
It's just a case of swapping
progress(params, ...);
with
if(!progress(params, ...)
cleanup_some_stuff_and_return_what_there_is();
Otherwise, I'll do it myself tomorrow.
Can anyone tell I've got time off work? ;-)
SVN revision: 2544
(gilbertt)
Changed all the loaders to use ImlibProgressFunction instead of defining it
themselves. This is so I can change them all at once tomorrow.
SVN revision: 2542
Tom Gilbert
Michael Jennings
Christopher Rosendahl
Corey Donohoe
Carsten Haitzler
Franz Marini
Platon Fomichev
Chris Ross
Peter Kjellerstedt