Commit Graph

22 Commits

Author SHA1 Message Date
Carsten Haitzler 5886f2a7cd and new much cleaner tree.
SVN revision: 12113
2004-11-01 09:45:31 +00:00
Carsten Haitzler 31660022d0 remooov!
SVN revision: 12112
2004-11-01 09:34:29 +00:00
Carsten Haitzler 84ec6d0504 up to 1.1.2 - security fixes, some other fixed, ilbm loader
SVN revision: 11452
2004-08-31 03:32:13 +00:00
Michael Jennings d83cddee16 Fri Jul 2 14:41:17 2004 Michael Jennings (mej)
Now builds properly on Vermillion, cAos, and CentOS.  Hopefully others
too.  :-)

SVN revision: 10667
2004-07-02 18:41:52 +00:00
Michael Jennings 723be4e698 Sat Jul 12 21:33:20 EDT 2003

Up version numbers.

SVN revision: 7162
2003-07-13 01:35:08 +00:00
Michael Jennings 7c65468d34 Sat Jul 12 21:06:14 EDT 2003

Patch from Yuri Hudobin <>
for Freetype2 support.

SVN revision: 7158
2003-07-13 01:09:17 +00:00
Michael Jennings e62412cdf2 Thu Apr 3 20:48:27 EST 2003

Minor tweak which apparently helps portability.

SVN revision: 6823
2003-04-04 01:49:41 +00:00
Michael Jennings 103226eb98 Thu Apr 3 14:06:53 EST 2003

Rearranged include directory order to make sure
local headers are found before system ones.

SVN revision: 6821
2003-04-03 19:08:17 +00:00
Michael Jennings cab8f00e06 Mon Mar 31 15:20:43 EST 2003

Finally got around to fixing the build.  Having Imlib2 already installed
should no longer be necessary to build it.

PS:  The next person who breaks this will be in for a severe beating.

SVN revision: 6800
2003-03-31 20:23:19 +00:00
Michael Jennings bf8bae5809 Tue Jan 15 15:22:06 EST 2002

Fixed a whole slew of potential buffer overflows, hopefully including
the one recently posted to BUGTRAQ.

SVN revision: 5838
2002-01-15 20:23:53 +00:00
Michael Jennings 64cbfee4fe Fri Aug 10 13:33:13 PDT 2001

None of the libraries are now absolute requirements.  Everything that
requires external support which Imlib2 itself doesn't specifically
need can now be optionally built.

SVN revision: 5090
2001-08-10 20:34:33 +00:00
Michael Jennings 8d141765c0 Wed Jul 12 22:20:53 PDT 2000

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

SVN revision: 2916
2000-07-13 05:04:36 +00:00
Tom Gilbert 1f9025dd97 Thu Apr 27 13:43:49 GMT 2000

Actually, made the gif loader give back what it's got without changing im->h
to reflect, or reallocing the image data. The reason for this is that it
already told apps what the image size was in the first progressive loader
callback, and changing it afterwards can cause confusion. Also, an app can
still handle/display a half-loaded image, as the rest is just filled black,
and the programmer knows how much of the image he got, 'cos he interrupted
it from the callback. If the programmer wants to trim the image, he knows
where to trim it, but if he/she wants to display a part-loaded image,
that'll work sanely.

I think this is more sane behaviour, having tested it in feh and
imlib2_view, but feel free to disagree ;-)

SVN revision: 2561
2000-04-27 12:37:20 +00:00
Tom Gilbert be906e1416 Thu Apr 27 13:41:11 GMT 2000

Free up some RAM and close the filehandle when interrupted.

SVN revision: 2560
2000-04-27 12:27:51 +00:00
Tom Gilbert 2aa32f702e Thu Apr 27 04:22:06 GMT 2000

Return 2 from interrupted loaders.

SVN revision: 2552
2000-04-27 03:09:22 +00:00
Tom Gilbert 0a7de7daf5 Thu Apr 27 04:00:28 GMT 2000

All done except the tiff loader. (Although I may be giving back incomplete
rows on a couple, I have to test more).
The tiff loader is gonna be hard, libtiff is quite broken in many ways ;-)

SVN revision: 2549
2000-04-27 02:53:20 +00:00
Michael Jennings ceec186cb7 Wed Apr 26 19:58:05 PDT 2000

If progress() returns 0, clip the last row and
return 2.

SVN revision: 2548
2000-04-27 02:46:26 +00:00
Tom Gilbert ed923261d4 Thu Apr 27 03:16:59 GMT 2000

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, ...);
if(!progress(params, ...)
Otherwise, I'll do it myself tomorrow.

Can anyone tell I've got time off work? ;-)

SVN revision: 2544
2000-04-27 02:14:59 +00:00
Tom Gilbert ef67431a5b Consolidate one ChangeLog in the root dir.
SVN revision: 2543
2000-04-27 01:51:07 +00:00
Carsten Haitzler 3a59c44b66 add TODO...
SVN revision: 1095
1999-11-01 12:11:30 +00:00
Mandrake 202c34558d Sun Oct 31 20:21:13 PST 1999

libltdl (large chunks of it) is automatically generated by
no need for those files to be in CVS.

SVN revision: 1084
1999-10-31 19:45:22 +00:00
Mandrake 0b21238956 Fri Oct 22 10:53:26 PDT 1999

removed almost all the warnings.
except for:
main.c:287: warning: implicit declaration of function `__imlib_draw_line'
which I believe is because it's not using the appropriate API call yet.

SVN revision: 945
1999-10-22 11:19:11 +00:00