Re: file-target
Christoph Egger writes: I have now produced a patch of my currently done work. The patch compiles for me, but I've nothing tested yet, so be beware. I post it, because I want have some comments about it. OK, some comments :). Looks pretty good so far. Except for the FILE_PPM and FILE_BMP defines -- are they just temporary ? Cheers, __ \/ Andrew Apted [EMAIL PROTECTED]
Re: file-target
On Thu, 3 Feb 2000, Andrew Apted wrote: Christoph Egger writes: I've some question: Is there any macro or any #define, that say at compile time, if libggi is compiled on a bigendian or on a littleendian architecture? There used to be... looking... It is in libgii/include/ggi/system.h and libgii/configure : GGI_LITTLE_ENDIAN GGI_BIG_ENDIAN One of those will be defined. I see. TNX. Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: file-target
On Thu, 3 Feb 2000, Andrew Apted wrote: Christoph Egger writes: I have now produced a patch of my currently done work. The patch compiles for me, but I've nothing tested yet, so be beware. I post it, because I want have some comments about it. OK, some comments :). Looks pretty good so far. Except for the FILE_PPM and FILE_BMP defines -- are they just temporary ? Yes, for now. If it will be removed or not, decides the further hacking... Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: ggv (Re: file-target)
On Wed, 2 Feb 2000, Cesar Crusius wrote: Good that someone talked about it. It never worked in my machine. Segfaults immediately... I tried to email the author to no avail. That's bad. Run it with GGI_DEBUG=255 ggv and send the output to the list. Maybe that someone could help you... Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: file-target
On Thu, 3 Feb 2000, Andrew Apted wrote: Christoph Egger writes: I have now produced a patch of my currently done work. The patch compiles for me, but I've nothing tested yet, so be beware. I post it, because I want have some comments about it. OK, some comments :). Looks pretty good so far. TNX. What do you think todo at the comments starting with "/* FIXME: ... */" ? Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: data type sizes
i found int ggiCrossBlit(ggi_visual *src, int sx, int sy, int sw, int sh, ggi_visual *dst, int dx, int dy); which has compiler dependend sizes. is this intended ? Yes. Compilers set int size to be the data size that is most efficient to handle. ggi won't work on a 8 bit computer with display size larger than 127 dots. for example the sinclair ZX Spectrum has 256 dots wide display. ;) Sure, but 8 bit computers tend to have 16 bits of adress space at max, which will be too small anyway to run a full blown LibGGI. So hacking it would be necessary anyway. No, LibGGI expects ANSI C at least. IIRC in ANSI C 16 bits is as small as int can get. To be precise, ANSI states, that int must have a range of -32767 to 32767 at least. (Mind the symmetric range). CU, ANdy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Re: file-target
+struct file_type_op_t file_type[] =
+{
+{ "ppm", _ggi_file_detect_ppm, NULL, _ggi_file_ppm_write },
+{ "bmp", _ggi_file_detect_bmp, _ggi_file_bmp_read, NULL },
+{ NULL, NULL, NULL, NULL }
+};
Hmm - I'd like it better, if it would read only P?M and use ppmtools to
convert any other format as required.
+/* Read primitives */
+
+void _ggi_file_read_byte(ggi_visual *vis, int *val)
+{
+ FileHook *ff = FILE_PRIV(vis);
+
+#if 0
+ if (ff-buf_len 0) {
+ (uint8) val = ff-buffer[ff-buf_len++];
+ return;
+ }
+
+ if ((ff-buf_len = read(LIBGGI_FD(vis), ff-buffer, FILE_BUFFER_SIZE) 0) {
+ perror("display-file: read error");
+ }
+
+ if (ff-buf_len FILE_BUFFER_SIZE) {
+ /* FIXME: eof is reached */
+ }
+#else
+
+ if ((ff-buf_len = read(LIBGGI_FD(vis), ff-buffer, 1)) 0) {
+ perror("display-file: read error");
+ }
+
+ if (ff-buf_len == 0) {
+ /* FIXME: eof is reached */
+ }
+
+ (uint8)(*val) = (uint8)(ff-buffer[0]);
+#endif
+}
Why don't you just use a file-stream and leave buffering to the libc ?
+void _ggi_file_read_word(ggi_visual *vis, int *val)
+{
+#ifdef GGI_LITTLE_ENDIAN
+ _ggi_file_read_byte(vis, (int*)(val) );
+ _ggi_file_read_byte(vis, (int*)(val+1) );
+#else
+ _ggi_file_read_byte(vis, (int*)(val+1) );
+ _ggi_file_read_byte(vis, (int*)(val) );
+#endif
+}
Uh - please don't do this. There is sick stuff like PDP byte ordering and
the code you have here doesn't do what you want (reading two bytes into
a single int - right ?) anyway.
A better way would be to use something like
int sum=0
char byte;
read_byte(...,byte);sum =byte;
read_byte(...,byte);sum|=byte8;
This is not only independent of host byte ordering, it will also work.
+ for (; strlen 0; strlen--) {
More elegant: while(strlen--);
+ _ggi_file_read_byte(vis, (int*)(str));
This typecast is very ugly BTW. Moreover you will have to increase str, and
it will only work, if the host is little endian.
+/* FIXME: compiler fails on using this with: "sizeof applied to an incomplete type"
*/
+#define NUM_FILE_TYPES (sizeof(file_type) / sizeof(struct file_type_op_t))
You need to have a complete prototype for file_type_op_t included before you
can use sizeof.
CU, Andy
--
= Andreas Beck| Email : [EMAIL PROTECTED] =
Re: ggv (Re: file-target)
* Christoph Egger ([EMAIL PROTECTED]) [000203 07:38]:
That's bad. Run it with GGI_DEBUG=255 ggv and send the output to the
list. Maybe that someone could help you...
It was not a GGI problem. Here's the culprit:
*** config.c.orig Thu Feb 3 08:38:42 2000
--- config.cThu Feb 3 08:43:46 2000
***
*** 176,182
/* Quick check for something not set or missing */
for( x = 0; x 9 ; x++ )
{
! if(!strlen(cfg_data[x].data))
{
fprintf(stderr,"Error: %s= information not
set.\n",cfg_data[x].name);
return GGV_ERROR;
--- 176,182
/* Quick check for something not set or missing */
for( x = 0; x 9 ; x++ )
{
! if(!cfg_data[x].data || !strlen(cfg_data[x].data))
{
fprintf(stderr,"Error: %s= information not
set.\n",cfg_data[x].name);
return GGV_ERROR;
Well, now it displays image, but not correctly. If the image is small a
partial copy of it appears on the right side of the screen. My screen is
800x600 if someone wants to help. I can't set it to 640x480 because I'm
using a laptop, so I guess thats the problem. Anyone wanting to help?
--
Cesar Augusto Rorato Crusius o__ o__ o__ o__ o__
Stanford University ,/'_ ,/'_ ,/'_ ,/'_ ,/'_
e-mail:[EMAIL PROTECTED](_)\(_) (_)\(_) (_)\(_) (_)\(_) (_)\(_)
www.stanford.edu/~crusius
HE WHO SACRIFICES FUNCTIONALITY FOR EASE OF USE
LOSES BOTH AND DESERVES NEITHER
Re: file-target
Hmm - I'd like it better, if it would read only P?M and use ppmtools to
convert any other format as required.
I want to have reading some different file-formats and not only one.
That's why I hack the file-target.
This is a misconception IMHO.
The idea of the ppmtools is to finally put an end to reinventing the picture
loading and saving wheel for every program/lib/whatever.
As long as you can load/save ppms (which is trivial) you can load/save any
format by just piping the output through the appropriate ppmtools.
LibGGI is intended to be lightweight, and I'd like to keep it this way.
So what you should do is to use ppmtools to convert other filetypes to/from
ppm on the fly.
This saves lots of source (ever looked at the tiff spec ? about 300 pages
...) and legal problems as well (GIF ...).
Why don't you just use a file-stream and leave buffering to the libc ?
You mean, I should use FILE * from the libc?
Yes. We use it anyway, so no additional space (runtime-link-wise) required
for that one, and it usually has a well optimized buffering implementation
that is seekable and whatever.
+void _ggi_file_read_word(ggi_visual *vis, int *val)
+{
+#ifdef GGI_LITTLE_ENDIAN
+ _ggi_file_read_byte(vis, (int*)(val) );
+ _ggi_file_read_byte(vis, (int*)(val+1) );
+#else
+ _ggi_file_read_byte(vis, (int*)(val+1) );
+ _ggi_file_read_byte(vis, (int*)(val) );
+#endif
+}
Uh - please don't do this. There is sick stuff like PDP byte ordering and
Maybe, when I use the FILE * from the libc, that then bug is fixed.
The main bug is here:
+void _ggi_file_read_word(ggi_visual *vis, int *val)
+{
+ _ggi_file_read_byte(vis, (int*)(val) );
+ _ggi_file_read_byte(vis, (int*)(val+1) );
+}
val is a pointer to an integer. That means that val+1 will be the pointer to
the next integer (i.e. 4 bytes higher on x86). What you are probably trying
to achieve is to:
+ _ggi_file_read_byte(vis, (int*)((char *)val) );
+ _ggi_file_read_byte(vis, (int*)((char *)val+1) );
Which would place the second byte one byte above the first one to form a
little endian word.
+/* FIXME: compiler fails on using this with: "sizeof applied to an incomplete
type" */
+#define NUM_FILE_TYPES (sizeof(file_type) / sizeof(struct file_type_op_t))
You need to have a complete prototype for file_type_op_t included before you
can use sizeof.
I see. But maybe is file_type, not file_type_op_t, no?
That may be. Though the statement only makes sense to me, if file_type is
an array of type file_type_op_t - right ?
In that case if file_type_op_t is not completely defined, file_type can't be
completely either. There is one more possibility:
If file_type is an array, it must be declared _with_size_ before the define
(or rather its use). Stuff like export bla[] won't work.
CU, Andy
--
= Andreas Beck| Email : [EMAIL PROTECTED] =
Re: file-target
* Andreas Beck ([EMAIL PROTECTED]) [000203 13:09]: Hmm - I'd like it better, if it would read only P?M and use ppmtools to convert any other format as required. I want to have reading some different file-formats and not only one. That's why I hack the file-target. This is a misconception IMHO. The idea of the ppmtools is to finally put an end to reinventing the picture loading and saving wheel for every program/lib/whatever. As long as you can load/save ppms (which is trivial) you can load/save any format by just piping the output through the appropriate ppmtools. LibGGI is intended to be lightweight, and I'd like to keep it this way. Compile-time options and existing dynamic libraries can take care of this, but I think ppms can solve it too (see below). So what you should do is to use ppmtools to convert other filetypes to/from ppm on the fly. I almost agree, let me just clarify some points. I think it should be completely transparent. What I think you're suggesting, and what I would suggest, is to have this conversion built in the file target: when opening something that is not a ppm, file-target tries to find the correct ppmtool and spanws it in the background and gets the ppm through a pipe or whatever. The user is never aware of the conversion. My only con to this option is that its not really efficient both in terms of speed (spawns process, reads file, pipe file...) and memory (at some point two copies of the translated file have to be in memory, one for each pipe end --- and that can be a *real* problem in systems with relative with low memory, since ppms are not really good in saving memory --- swap, swap...). Ideally, some very common types could be built in. We have libjpeg.so (I think we even have libtiff.so), so there's almost no overhead in having jpegs. For GIFs, use the ppmtools scheme above (avoid legal problems). What I'm really against is implementing a complete jpeg reader from scratch, for example. It is more fficient to use libpng, libjpeg, libtiff, etc. Then it would be to pipe through conversion programs. As a last ditch effort a call to convert could be used(as in imlib), but normally a dlopen of a image-loader lib(again, as in imlib) is very efficient. I have a small program that dlopens libpng and displays a png image using GGI, but I did not implement it as the file-target :( Its really too bad that imlib isnt target independent, we should have something similar in GGI. I think we also really need some bindings into Hermes(efficient pixel-format conversion library). HE WHO SACRIFICES FUNCTIONALITY FOR EASE OF USE LOSES BOTH AND DESERVES NEITHER "Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one." -Thomas Jefferson -Adam Scislowicz([EMAIL PROTECTED])
Re: file-target
So what you should do is to use ppmtools to convert other filetypes to/from ppm on the fly. I almost agree, let me just clarify some points. I think it should be completely transparent. What I think you're suggesting, and what I would suggest, is to have this conversion built in the file target: when opening something that is not a ppm, file-target tries to find the correct ppmtool and spanws it in the background and gets the ppm through a pipe or whatever. The user is never aware of the conversion. Yes. Correct. You just give a filename and the file target will automatically determine the filetype (I'd say first from extension, and if that is unclear using the "file" utility or something). My only con to this option is that its not really efficient both in terms of speed (spawns process, reads file, pipe file...) Speed is IMHO no big concern when doing a ggiOpen. Loading the dynamic libs and stuff also has its price (and we do lots of these), so the extra overhead in speed should not be a big problem. File-IO is usually the limit anyway, so the extra task-switching overhead for piping stuff around should be pretty neglegible. and memory (at some point two copies of the translated file have to be in memory, one for each pipe end Yes. This is a very unfortunate side effect of bad coding in most ppmtools. I have solved my jpeg-encoding problem (on-the-fly encoding of scanner data to jpeg) on a server that was very low on RAM by using cjpeg instead of the corresponding ppmtool for gifs or tifs, as cjpeg is clever about encoding and only reads 8 lines at a time (which is needed due to the jpeg tile size). --- and that can be a *real* problem in systems with relative with low memory, since ppms are not really good in saving memory --- swap, swap...). Yes. However I think this problem is a minor one for the task at hand. If someone needs to load huge pictures and/or cares for speed, it should be obvious that implementing the stuff on its own would be better. As long as we have several alternatives, we can easily try them in a best-worst order, like trying djpeg before other less clever decoders. Ideally, some very common types could be built in. We have libjpeg.so (I think we even have libtiff.so), Yes. But both are not really small (100k and 300k), not always there and at least for using libjpeg the double-memory-consumption still holds, except I have overlooked some mode of operation that wasn't used in the programs I have seen. I'm really against is implementing a complete jpeg reader from scratch, for example. Yes. Libs might be acceptable, though I'd prefer them to be detected and used at runtime, if at all, to allow for better binary compatibility. Everything is fine, as long as only one format is really implemented in LibGGI to save double work and maintainer's nightmares. CU, ANdy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Re: file-target
On Thu, 3 Feb 2000, Andreas Beck wrote:
+struct file_type_op_t file_type[] =
+{
+{ "ppm", _ggi_file_detect_ppm, NULL, _ggi_file_ppm_write },
+{ "bmp", _ggi_file_detect_bmp, _ggi_file_bmp_read, NULL },
+{ NULL, NULL, NULL, NULL }
+};
Hmm - I'd like it better, if it would read only P?M and use ppmtools to
convert any other format as required.
I'd prefer PNG myself. Or JPEG. Or better, both.
At least with those I know my videodata's stored properly :)
[png up to 48bpp RGB, JPEG stores in YCbCr which I'd rather have for
pictures... :]
And I can't afford the 100Megs it takes to store the ppmtools.
(exageration - it's ~25-40MB depending on compile options). Or have to
hunt down one that will -compile- on my computer. *sigh*
Why don't you just use a file-stream and leave buffering to the libc ?
It's handy for overriding to read from sources -other- than files? :)
(ie: network connections [okay poor example], messaging systems *giggle*,
WWW connections preformatted files ie embedded WWW or gzipped... :)
Oh yeah, and you can support 64bit access too. For files 2GB in size :)
+/* FIXME: compiler fails on using this with: "sizeof applied to an incomplete
type" */
+#define NUM_FILE_TYPES (sizeof(file_type) / sizeof(struct file_type_op_t))
You need to have a complete prototype for file_type_op_t included before you
can use sizeof.
Unless it's a (void*) which is how I normally HANDLE it *giggle*
Anyways, G'day, eh? :)
- Teunis
PS: ignore me if ya want. i'm just a crank...
