[patch]: file-target fixes
Hi all,
I have created a patch (attached), which fixes one typo error, some
little/big-endian -stuff and also does some cleanups.
Is anyone here to get the patch into the cvs-tree?
Thanks in advance,
Christoph Egger
E-Mail: [EMAIL PROTECTED]
diff -uNr 2130/degas/lib/libggi/display/file/fileio.c
degas/lib/libggi/display/file/fileio.c
--- 2130/degas/lib/libggi/display/file/fileio.c Tue Apr 13 07:07:28 1999
+++ degas/lib/libggi/display/file/fileio.c Sun Feb 6 20:43:58 2000
@@ -36,7 +36,7 @@
#include ggi/internal/ggi-dl.h
#include ggi/display/file.h
-
+#include ggi/system.h
int _ggi_file_create_file(ggi_visual *vis, char *filename)
{
@@ -99,8 +99,24 @@
void _ggi_file_write_word(ggi_visual *vis, int val)
{
+#ifdef GGI_LITTLE_ENDIAN
_ggi_file_write_byte(vis, val 8);
_ggi_file_write_byte(vis, val 0xFF);
+#else
+ _ggi_file_write_byte(vis, val 0xFF);
+ _ggi_file_write_byte(vis, val 8);
+#endif
}
void _ggi_file_write_string(ggi_visual *vis, char *str)
@@ -112,7 +128,31 @@
void _ggi_file_write_zeros(ggi_visual *vis, int count)
{
- for (; count 0; count--) {
+ while (count--) {
_ggi_file_write_byte(vis, 0);
}
}
diff -uNr 2130/degas/lib/libggi/display/file/mode.c
degas/lib/libggi/display/file/mode.c
--- 2130/degas/lib/libggi/display/file/mode.c Mon Dec 13 07:10:45 1999
+++ degas/lib/libggi/display/file/mode.cSun Feb 6 20:46:08 2000
@@ -46,11 +46,12 @@
#define MAP_FAILED ((void*)-1)
#endif
-#define write_byte_ggi_file_write_byte
-#define write_word_ggi_file_write_word
-#define write_string _ggi_file_write_string
-#define write_zeros _ggi_file_write_zeros
-#define write_flush _ggi_file_flush
+#define write_byte _ggi_file_write_byte
+#define write_word _ggi_file_write_word
+#define write_string _ggi_file_write_string
+#define write_zeros_ggi_file_write_zeros
+#define write_flush_ggi_file_flush
static void dowritefile(ggi_visual *vis)
{
@@ -427,7 +428,7 @@
err--;
}
- if (mode-virt.x mode-visible.x) {
+ if (mode-virt.y mode-visible.y) {
mode-virt.y = mode-visible.y;
err--;
}
diff -uNr 2130/degas/lib/libggi/display/file/visual.c
degas/lib/libggi/display/file/visual.c
--- 2130/degas/lib/libggi/display/file/visual.c Sat Jan 30 07:08:17 1999
+++ degas/lib/libggi/display/file/visual.c Sun Feb 6 20:48:51 2000
@@ -33,14 +33,21 @@
#include ggi/internal/ggi-dl.h
#include ggi/display/file.h
-#define NUM_OPTS 3
-static gg_option file_options[NUM_OPTS] =
+static gg_option file_options[] =
{
{ "flushcmd", "" },
{ "flushframe", "0" },
{ "flushtime", "0.0" }
};
+#define OPT_FLUSHCMD 0
+#define OPT_FLUSHFRAME 1
+#define OPT_FLUSHTIME 2
+
+#define NUM_OPTS (sizeof(file_options)/sizeof(gg_option))
+
+
+
int GGIdlinit(ggi_visual *vis, const char *args,void *argptr)
{
FileHook *ff;
@@ -87,9 +94,9 @@
}
ff-filename = strdup(args);
- ff-flushcmd = file_options[0].result[0] ? strdup(file_options[0].result) :
NULL;
- ff-flushevery = atoi(file_options[1].result);
- fltime = atof(file_options[2].result);
+ ff-flushcmd = file_options[OPT_FLUSHCMD].result[0] ?
+strdup(file_options[OPT_FLUSHCMD].result) : NULL;
+ ff-flushevery = atoi(file_options[OPT_FLUSHFRAME].result);
+ fltime = atof(file_options[OPT_FLUSHTIME].result);
ff-flushcnt = 0;
ff-flushtotal = 0;
gettimeofday(ff-flushlast,NULL);
Re: [patch]: file-target fixes
I have created a patch (attached), which fixes one typo error, some
little/big-endian -stuff and also does some cleanups.
Is anyone here to get the patch into the cvs-tree?
I will commit it, though with the following changes:
void _ggi_file_write_word(ggi_visual *vis, int val)
{
+#ifdef GGI_LITTLE_ENDIAN
_ggi_file_write_byte(vis, val 8);
_ggi_file_write_byte(vis, val 0xFF);
+#else
+ _ggi_file_write_byte(vis, val 0xFF);
+ _ggi_file_write_byte(vis, val 8);
+#endif
}
That is nonsense IMHO. If a fileformat has LE or BE words will rarely change
depending on the architecture we are running on. I split the function to
two:
void _ggi_file_write_BE_word(ggi_visual *vis, int val)
{
_ggi_file_write_byte(vis, (val 8) 0xff);
_ggi_file_write_byte(vis, val 0xff);
}
void _ggi_file_write_LE_word(ggi_visual *vis, int val)
{
_ggi_file_write_byte(vis, val 0xff);
_ggi_file_write_byte(vis, (val 8) 0xff);
}
CU, ANdy
--
= Andreas Beck| Email : [EMAIL PROTECTED] =
Re: [patch]: file-target fixes
On Sat, 26 Feb 2000, Andreas Beck wrote:
I have created a patch (attached), which fixes one typo error, some
little/big-endian -stuff and also does some cleanups.
Is anyone here to get the patch into the cvs-tree?
I will commit it, though with the following changes:
void _ggi_file_write_word(ggi_visual *vis, int val)
{
+#ifdef GGI_LITTLE_ENDIAN
_ggi_file_write_byte(vis, val 8);
_ggi_file_write_byte(vis, val 0xFF);
+#else
+ _ggi_file_write_byte(vis, val 0xFF);
+ _ggi_file_write_byte(vis, val 8);
+#endif
}
That is nonsense IMHO. If a fileformat has LE or BE words will rarely change
depending on the architecture we are running on. I split the function to
two:
void _ggi_file_write_BE_word(ggi_visual *vis, int val)
{
_ggi_file_write_byte(vis, (val 8) 0xff);
_ggi_file_write_byte(vis, val 0xff);
}
void _ggi_file_write_LE_word(ggi_visual *vis, int val)
{
_ggi_file_write_byte(vis, val 0xff);
_ggi_file_write_byte(vis, (val 8) 0xff);
}
OK - I agree.
Christoph Egger
E-Mail: [EMAIL PROTECTED]
Re: file-target - just a quick comment on 64bit....
Just remembered this thread. This doesn't really apply to file-target really but it'd be good to remember for anyone reading/writing image libs. Of course a good solution for image libs is to support reading from stdin and writing to stdout :) [the calling proggy can deal with the probs.. :] On Fri, 4 Feb 2000, Christian Reiniger wrote: teunis wrote: Oh yeah, and you can support 64bit access too. For files 2GB in size :) If stdio the underlying FS don't support 64bit access, then it doesn't make much sense to use it anyway. After all, where do you want to store these 2GB? ;) Well, to take the linux/x86 example: ext2fs [afaik] does support 2GB files... stdio does -not- support 64bit access There's a suite of calls to talk to 2GB files with 64bit access. - 64bit file access is a special case on intel architecture; afaik Alpha/linux had it first as native for linux... - glibc 2.0+ has 64bit support... I haven't tested 'stdio' as I don't have 2GB set aside for running this... yet Actually I don't think the 64bit filesystem access is necessary for file-[target]; but for an image reader it would be appropriate... Just FWIW. G'day, eh? :) - Teunis
Re: [patch]: file-target
[EMAIL PROTECTED] (Christoph Egger) writes: Marcus, do you accept the attached patch? The patch compiles and works for me. It holds some cleanups, optimisations and one bugfix in checkmode. Looks mostly fine to me except the added unused functions. //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: [patch]: file-target
On 19 Feb 2000, Marcus Sundberg wrote: [EMAIL PROTECTED] (Christoph Egger) writes: Marcus, do you accept the attached patch? The patch compiles and works for me. It holds some cleanups, optimisations and one bugfix in checkmode. Looks mostly fine to me except the added unused functions. You may remove the unused functions. I just thought, that the _currently_ unsused added functions may be good helpers for future developements... Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: file-target
The purpose of the file-target is to transparently render a LibGGI application's output to a file. And the application's output can be _anything_. And "anything" means, that this could be also a screenshot for example, which is usually saved as *.pcx, *.ppm or something like that. That is the idea, and that is already possible with the file target. Have a look at doc/targets.txt . The target itself will only write the simple raw and ppm formats and has hooks to externally convert them. Making it _read_ files does not gain you anything over any other approach, and is plain wrong. No. You can easily write a ggiviewer for example (have a look at the attachment). Yes. But thinking closely, Marcus is pretty much right. I have for now only argued with respect to bloating the file target. While IMHO a p?m loader wouldn't add much bloat, Marcus is right with the "we need a good image loading library anyway" argument. LibGGI programs keep reinventing this over and over, and I have done so myself as well several times for loading P?M, GIF and JPG. As Marcus said, it would be a good idea to have a generic lib not tied to LibGGI or whatever in any way, that can just load images. Anyone can use it, then. I myself would be one of the first customers, as I do image processing at the university and have both LibGGI-using and commandline-only programs that have to load/save images. Separating the image-loader from LibGGI would be good there ... (right now I use a memvisual-only mode for that, but actually that's a bit of overkill). It would be good, though, not to repeat the old error of tons of other libs to first load the image into some in-memory structure and then go on. While this is o.k. for say an icon or a background image of a few MB, it hits your swap very badly once you go to high resolution scans for DTP purposes etc. I have been hit by that bad practice lots of times when scanning and postprocessing the stuff. Even simple conversions filled up my RAM and swap without any need. For my image-processing stuff, it's even worse: We often work with tomography data what means 512x512x256 pixels at 16 bit/pixel ... 128MB of raw data ... Newer systemswill produce even better resolution ... IMHO we should, while we are at it, implement a lib that does the storage part (or the reading part, if we also implement saving images) by using a user-provided callback. That will allow us to directly load into memory visuals or similar and others to push it into memory or whatever. This callback is also a nice hooking point, where you can layer it with a colorspace conversion utility. Jpegs already contain yuv-data ... why waste time on converting that to rgb and then back to yuv to display it on a video out card. So the lib should just announce the format it will have in its callback-buffers and leave it to a higher level to do conversions. I have read someone here has some image loading lib already. Could you make a preview available ? We should probably adopt it into our development tree to be able to improve it together. With such a lib below, it should be pretty trivial to implement image loading in any LibGGI application. CU, Andy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Re: file-target; Console-utils?
On Sat, 5 Feb 2000 [EMAIL PROTECTED] wrote: on libggiImg: Release it please :) I suspect SOMEONE will help ya finish it. Unless you're having problems with design [clip libggittf] ooohhh... toy! *cool*. I -could- use that right now :) Yes, I keep redesigning it, although this time I promise Ill release both libggiImg and libggittf regardless of there design, I am sure others will be able to polish them off from there. Oh please please. But DO include a wishlist - it'll help others in redesigning same too. Now this reference I don't get. Could you explain? We need some nice command line programs for setmode, screendump, I guess we dont need the other utils in console-tools though, at least not in the same capacity. They are mostly setfont, setcmap, setleds, openvt, chvt... Okay. setmode -- fbset? screendump Ahh, this should be easy in practice but isn't... (what's this do anyways?) setfont - now this could open up a -whole- kettle of fish. Are FB-fonts limited in size? ... I actually don't recognise these functions - what kit are they in and where do I get it? G'day, eh? :) - Teunis
Re: file-target
On Sun, 6 Feb 2000, Andrew Apted wrote: Marcus Sundberg writes: Well, Andrew is wrong. The functionality does not belong there, and you gain nothing by putting it there. Imagine this: one process using display-file to output (via mmap) a constantly changing image to a file. Another process using display-file to read that image (again via mmap) and displaying it. There are no-doubt other ways of achieve the same thing, but could it get any simpler (and more intuitive) than that ? Now you're seeing what I was planning for that @#%@% movie player. The silly beast is becoming multitasking now... turns out multithreading works -beautifully- if you use wait states properly. Actually the beast is better at playing mp3's on my computer than mpg123 thanks to this :) But you need a fast enough CPU... Anyways, another part of such an exchange is some for of coordination between reader and writer on when the screen is safe for update... (isn't memory-target better for this? :) G'day, eh? :) - Teunis
Re: file-target; Console-utils?
Yes, I keep redesigning it, although this time I promise Ill release both libggiImg and libggittf regardless of there design, I am sure others will be able to polish them off from there. Oh please please. But DO include a wishlist - it'll help others in redesigning same too. Now this reference I don't get. Could you explain? We need some nice command line programs for setmode, screendump, I guess we dont need the other utils in console-tools though, at least not in the same capacity. They are mostly setfont, setcmap, setleds, openvt, chvt... Okay. setmode -- fbset? screendump Ahh, this should be easy in practice but isn't... (what's this do anyways?) setfont - now this could open up a -whole- kettle of fish. Are FB-fonts limited in size? ... I actually don't recognise these functions - what kit are they in and where do I get it? console-tools: http://www.altern.org/ydirson/en/lct/ http://altern.org/ydirson/soft/lct/dev/console-tools-0.3.3.tar.gz It is very similar to the kbd package, but with unicode support, and a few other additional features. -Adam Scislowicz ([EMAIL PROTECTED])
Re: file-target - could we stop it ?
O.K. folks ... I think we heard enough opinions about the pros and cons of implementing image loading in the file target. Let's summarize: Pro: - It is simple to use for LibGGI-aware applications. Con: - It doesn't help non-LibGGI-aware applications while a separate lib would. - If it implements more than a few file formats internally or via libs (even if they are dynamically loaded: they have no common calling interface, so at least glue code is added for every format), it bloats the file target and/or its dependencies. - If it implements only a few formats, we will always have some people left over that complain why it won't load format xyz. - It is inconsistent regarding the calling interface as it either needs to be readonly (which mean you have to write a special renderer set for it for that to work correctly) or it would magically work without SetMode, which is undefined behaviour on other targets. Now let's see what we can do about that conflict. My opinion: 1. Marcus is right: We need a generic and _really_good_ image reading/writing library anyway. We have quite some good standalone libs for the individual formats, but they lack a common calling interface. While it is true, that it is pretty hard to make a universal interface that takes account of all the possible extensions and features of all formats, it should be easily possible to make one that does the basic jobs of image loading and saving. 2. So I'd suggest we design and write that one first. As said I have some design ideas about that, and probably others have some as well from some frustrations with other libs. 3. When this is done, we have a _single_ library that will load/save any picture for us. As we design it, I image it to be like LibGGI with pluggable libs for the file formats, so no bloat at runtime. 4. Now, if there is still desire to add that functionality to the file target, we can do so by linking to _JUST_ONE_ lib and adding a _FEW_ lines of code (say less than 100) to it. This path solves the first three cons very nicely. Regarding the last one: If there is demand for it, and it doesn't add much bloat - why not. One doesn't have to use the feature, in which case all is nice and consistent. It might as well be, that after we have the loader lib, noone still wants it, so let's delay the discussion until the work is done. Let's get something done (you all know that I hate the "no action talk only" syndrome): 1. Someone please propose an external API for an image loader/writer. At best one that already exists with working code attached to it. 2. We will then discuss it and improve it until we are satisfied. 3. We will the implement it or restructure existing code to work like LibGGI dynamically loading loaders/writers as required. 4. We add libs for all known/documented file formats, starting from "use ppmtools" stubs to have a catchall system from scratch. 5. We write a few glue components that take care of colorspace conversion and image representation/transfer. O.K. - let's go ... task 1. is on schedule ... CU, Andy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Re: file-target - could we stop it ?
On Sun, 6 Feb 2000, Andreas Beck wrote:
Let's get something done (you all know that I hate the "no action talk only"
syndrome):
1. Someone please propose an external API for an image loader/writer. At
best one that already exists with working code attached to it.
2. We will then discuss it and improve it until we are satisfied.
3. We will the implement it or restructure existing code to work like LibGGI
dynamically loading loaders/writers as required.
4. We add libs for all known/documented file formats, starting from "use
ppmtools" stubs to have a catchall system from scratch.
5. We write a few glue components that take care of colorspace conversion
and image representation/transfer.
O.K. - let's go ... task 1. is on schedule ...
attached. The code doesn't compile yet, but it could work...
Christoph Egger
E-Mail: [EMAIL PROTECTED]
/*
**
bitmap overview
Copyright (C) 1999-2000 Christoph Egger [[EMAIL PROTECTED]]
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the "Software"),
to deal in the Software without restriction, including without limitation
the rights to use, copy, modify, merge, publish, distribute, sublicense,
and/or sell copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
THE AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
**
*/
#include stdlib.h
#include string.h
#include limits.h
typedef struct bitmap_type_info_t
{
char *ext;
int (*load)(void **data, char *filename);
int (*save)(void **data, char *filename);
} bitmap_type_info_t;
static struct bitmap_type_info_t bitmap_types[] =
{
{ "bmp", load_bmp, save_bmp },
{ "lbm", load_lbm, NULL },
{ "pcx", load_pcx, save_pcx },
{ "tga", load_tga, save_tga },
{ NULL, NULL, NULL },
{ NULL, NULL, NULL },
{ NULL, NULL, NULL },
{ NULL, NULL, NULL },
{ NULL, NULL, NULL },
{ NULL, NULL, NULL },
{ NULL, NULL, NULL },
{ NULL, NULL, NULL },
{ NULL, NULL, NULL },
{ NULL, NULL, NULL },
{ NULL, NULL, NULL },
{ NULL, NULL, NULL }
};
#define MAX_BITMAP_TYPES (sizeof(bitmap_types) / sizeof(bitmap_type_info_t))
/* register_bitmap_file_type:
* Informs of a new image file type, telling it how to load and
* save files of this format (either function may be NULL).
*/
void register_bitmap_file_type(char *ext,
int (*load)(void **data, char *filename), int (*save)(void **data,
char *filename))
{
int i;
for (i=0; iMAX_BITMAP_TYPES; i++) {
if ((!bitmap_types[i].ext) || (strcmp(bitmap_types[i].ext, ext) == 0)) {
bitmap_types[i].ext = ext;
bitmap_types[i].load = load;
bitmap_types[i].save = save;
return;
}
}
}
/* load_bitmap:
* Loads a bitmap from disk.
*/
int load_bitmap(void **data, char *filename)
{
int i;
for (i=0; iMAX_BITMAP_TYPES; i++) {
if ((bitmap_types[i].ext)
(strcmp(bitmap_types[i].ext, get_extension(filename)) == 0)) {
if (bitmap_types[i].load)
return bitmap_types[i].load(data, filename);
else
return -1;
}
}
return -1;
}
/* save_bitmap:
* Writes a bitmap to disk.
*/
int save_bitmap(void **data, char *filename)
{
int i;
for (i=0; iMAX_BITMAP_TYPES; i++) {
if ((bitmap_types[i].ext)
(strcmp(bitmap_types[i].ext, get_extension(filename)) == 0)) {
if (bitmap_types[i].save)
return bitmap_types[i].save(data, filename);
else
return -1;
}
}
return -1;
}
/*
**
bitmap overview
Copyright (C) 1999-2000 Christoph Egger [[EMAIL PROTECTED]]
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the "Software"),
to deal in the
Re: file-target
Andrew Apted [EMAIL PROTECTED] writes: Imagine this: one process using display-file to output (via mmap) a constantly changing image to a file. Another process using display-file to read that image (again via mmap) and displaying it. There are no-doubt other ways of achieve the same thing, but could it get any simpler (and more intuitive) than that ? The reading process must be specially written to do this, so it might just as well use the image library to read the image into a visual, and it can do that using fewer function calls than using a bastardized file-target would. As for intuitive, I don't think targets reading images netiher is very much intuitive or a clean solution. //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: file-target
[EMAIL PROTECTED] (Christoph Egger) writes: So when we write two libraries, to load and save images - Should the file-target then be removed? No, because as I said: The purpose of the file-target is to transparently render a LibGGI application's output to a file. //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: file-target
On Fri, 4 Feb 2000, Andreas Beck wrote: 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. [clip] -rwxr-xr-x 1 root root19408 Mar 21 1999 /usr/bin/djpeg And I can't afford the 100Megs it takes to store the ppmtools. You only need to install those you need ... Since when? You always have to compile everything. Maybe that should be something that gets attacked GGI-style. Make a nice config script and controllable install of ppmtools :) Be handy. Especially with people with -very- little HD space and need only of one or two tools. (this is why I'm annoyed with ppmtools... I rarely have space to play with them or at least not 'til now :) [clip] (ie: network connections [okay poor example], messaging systems *giggle*, WWW connections preformatted files ie embedded WWW or gzipped... :) These can all be trivially handled by simple filters using pipes, which is very very simple using popen. It's the power of unix to be able to pipe stuff around. I don't know the difference between using FILE* and file handles. I always use file handles myself as I'm frequently multitasking and passing things like sockets and the like around. Oh, and there should be a way to pass FILE* or file-handles (preferably file-handles) to file-target in GGI. That way, the program can send data to it invisibly :) Just because FILE* can't talk to databases or 64bit files or embedded WWW pages or doesn't mean it can't be used :) Also, NO TEMPORARY FILES UNLESS THE CALLING PROGRAM SETS THEM UP. YOU try playing with an uncompressed high-resolution scan 80 megabytes in size. Then watching subprograms create temporary copies. VERY pet peeve. (even worse when working with movies... when the results compressed are 2 gigabytes. *ow*) Anyways, that's all. This is the... uh... 10th or so time I've written this message and I'm getting a little tired of pine losing it on me. *sigh* G'day, eh? :) - Teunis
Re: file-target
On Sat, 5 Feb 2000, Christoph Egger wrote: On 5 Feb 2000, Marcus Sundberg wrote: [EMAIL PROTECTED] (Christoph Egger) writes: Is anyone here already hacking the file-target? If not, I want to hack it to add support reading some file-formats This is a completely broken idea. Having a target reading images like this makes about as much sense as having LibGII inputlibs read images, and it does not do anything good for anybody. I think, libggi couldn't be compared with libgii, because of the different goals, which they are designed for - even libggi uses libgii. If you want to load images into a LibGGI visual, write a library that loads them into a memory visual. What do _you_ think what is the idea behind of the file-target? Christoph Egger E-Mail: [EMAIL PROTECTED] P.S.: I will send you the latest patch personally to you. So you can rethink your opinion. Maybe that not all of the currently done work is not useful. The patch is attached. Christoph Egger E-Mail: [EMAIL PROTECTED] file_target.diff.bz2
Re: file-target
On Sun, 6 Feb 2000, Andrew Apted wrote: Christoph Egger writes: Andreas Beck ([EMAIL PROTECTED]) [000203 13:09] wrote: 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. Uhm, I assumed at the beginning, that the RAW-file-format, which is already implemented by Andrew, is designed for every program/lib/whatever... Nooope, it was just designed as something the file-target could MMAP, and update it the easy way (just writing to memory). Part of that design was that it could run directly on an /dev/fb* device (via MMAP), and still see the right image (within reason, e.g. a few lines of garbage at the top, and only working on certain fbdev modes that use the exact same format, and no palette setting). Uhm, and what sense does the fbdev-target make? Or perhaps the question should be: What sense does the RAW format, because of the existing fbdev-target? Or perhaps the question should be: What is the difference between the RAW format and the fbdev-target? Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: file-target
[EMAIL PROTECTED] (Christoph Egger) writes: If you want to load images into a LibGGI visual, write a library that loads them into a memory visual. What do _you_ think what is the idea behind of the file-target? The purpose of the file-target is to transparently render a LibGGI application's output to a file. Making it _read_ files does not gain you anything over any other approach, and is plain wrong. Especially considering that you can't do anything with a visual until you have set a mode, and ggiSetMode() clears the visual... //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: file-target
On 5 Feb 2000, Marcus Sundberg wrote:
[EMAIL PROTECTED] (Christoph Egger) writes:
If you want to load images into a LibGGI visual, write a library
that loads them into a memory visual.
What do _you_ think what is the idea behind of the file-target?
The purpose of the file-target is to transparently render a LibGGI
application's output to a file.
And the application's output can be _anything_. And "anything" means, that
this could be also a screenshot for example, which is usually saved as
*.pcx, *.ppm or something like that.
Making it _read_ files does not gain you anything over any other
approach, and is plain wrong.
No. You can easily write a ggiviewer for example (have a look at the
attachment).
Especially considering that you can't do anything with a visual
until you have set a mode, and ggiSetMode() clears the visual...
I can't follow you here. Please explain it more detailed.
Christoph Egger
E-Mail: [EMAIL PROTECTED]
#include ggi/ggi.h
#define TEST_FILE author_19.bmp
int main(int argc, char *argv[])
{
ggi_visual_t vis, file_vis;
ggi_mode *tm;
if (ggiInit() 0)
return 1;
vis = ggiOpen(NULL);
file_vis = ggiOpen("display-file:./author19.bmp");
ggiCheckMode(file_vis, tm);
ggiSetMode(vis, tm);
ggiCrossBlit(file_vis, 0,0, tm-virt.x,tm-virt.y, vis,0,0);
do {} while ( !ggiGetc(vis));
ggiClose(file_vis);
ggiClose(vis);
ggiExit();
}
Re: file-target
[EMAIL PROTECTED] (Christoph Egger) writes: And what is the sense? (see below too!) What I have already said several times - to do something sane instead of an ugly kludge. The ggiCheckMode() and ggiCrossBlit() in your program invokes undefined behaviour, because you have not set a mode on file_vis. If you did set a mode on file_vis it would be all black. No. It's not a undefined behaviour. Look: On Wed, 2 Feb 2000, Andrew Apted wrote: Christoph Egger writes: Is anyone here already hacking the file-target? No, I'm pretty sure no one is working on it. If not, I want to hack it to add support reading some file-formats (i.e. bmp, tga, pcx). Go ahead, it would be good. Semantics wise, you should load the file at init time, determine the properties (width, height, depth). Then make the CheckMode primitive set any GGI_AUTO values to the same as the file, and make the SetMode refuse any mode that doesn't match the file (unless you want to support scaling/depth conversion... :-). Make all write primitives (putpixel, drawline, etc) fail, and only support the read primitives (you will only need GetPixel_NC to get an initial prototype working). Well, Andrew is wrong. The functionality does not belong there, and you gain nothing by putting it there. //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: file-target
[EMAIL PROTECTED] (Christoph Egger) writes: Well, I asked you: What do _you_ think what is the idea behind of the file-target? And you answered: The purpose of the file-target is to transparently render a LibGGI application's output to a file. So, you have contradict yourself. :) Huh? If you find two contradictory statements of mine in this thread you are welcome to show them to me. What do you think, how the application should render the output to a file? If the application writer wants to create images and write them to disk he may use whatever method he likes. That's not what this thread is about. Rendering to a file is the same as something save to a file, isn't it? Not necessarily, but what has that got to do with anything? You are talking about making the file target read files, and I'm telling you it should not do that. //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: file-target; Console-utils?
On Sat, 5 Feb 2000 [EMAIL PROTECTED] wrote: [clip] on libggiImg: Release it please :) I suspect SOMEONE will help ya finish it. Unless you're having problems with design I am sorry to have not yet made libggiImg available, I have been too busy with work, and research :( I also have a mostly working libggittf which renders true type fonts, and uses libdb for caching of glyphs, it uses freetype as its backend. ooohhh... toy! *cool*. I -could- use that right now :) -Adam Scislowicz([EMAIL PROTECTED]) P.S: we need something like console-utils for KGI/GII/GGI... Now this reference I don't get. Could you explain? G'day, eh? :) - Teunis PS: If it means getting a console-emu up with graphics support and/or fonts... uhmm, maybe? I've got operational job control now so it should be duable. Except that GGI doesn't really like child processes still tracking that one down 'xcept I have other bugs too so...
Re: file-target
Christoph Egger writes: Uhm, and what sense does the fbdev-target make? Or perhaps the question should be: What sense does the RAW format, because of the existing fbdev-target? Or perhaps the question should be: What is the difference between the RAW format and the fbdev-target? The RAW format has a header, with the width, height, graphtype, and palette for GT_PALETTE modes. The header is aligned to the stride value, so for anyone silly enough (like me :-) it can be run directly on a /dev/fb* device itself (nothing to do with the fbdev-target, I'm talking about the actual devices files in /dev). I can do this: demos/flying-ggis -m 1024x760x16 -t file:/dev/fb0 (I boot with vesafb into 1024x768x16 mode). It works. It's ultra silly too. No input. Needed SAK to kill :- Cheers, __ \/ Andrew Apted [EMAIL PROTECTED]
Re: ggv (Re: file-target)
On Thu, Feb 03, 2000 at 08:54:03AM -0800, Cesar Crusius wrote: 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? This happens for me too. -- Niklas
Re: file-target
teunis wrote: 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... :) Seconded. But normal stdio access needs to be supported (as default), as otherwise "normal" usage would be unneccessarily complicated. Oh yeah, and you can support 64bit access too. For files 2GB in size :) If stdio the underlying FS don't support 64bit access, then it doesn't make much sense to use it anyway. After all, where do you want to store these 2GB? ;) +/* 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* but sizeof (void *) isn't exactly what he wants here ;) Christian -- Daddy what does "FORMATING DRIVE C" mean?
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: 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...
Re: file-target
On Wed, 2 Feb 2000, Christoph Egger wrote: On Wed, 2 Feb 2000, Andrew Apted wrote: Christoph Egger writes: Is anyone here already hacking the file-target? No, I'm pretty sure no one is working on it. If not, I want to hack it to add support reading some file-formats (i.e. bmp, tga, pcx). Go ahead, it would be good. Semantics wise, you should load the file at init time, determine the properties (width, height, depth). Then make the CheckMode primitive set any GGI_AUTO values to the same as the file, and make the SetMode refuse any mode that doesn't match the file (unless you want to support scaling/depth conversion... :-). Make all write primitives (putpixel, drawline, etc) fail, and only support the read primitives (you will only need GetPixel_NC to get an initial prototype working). Hope that helps. Yes, THX! I will do so. OK - I've started hacking on it. 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? Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: file-target
On Wed, 2 Feb 2000, Christoph Egger wrote: On Wed, 2 Feb 2000, Christoph Egger wrote: On Wed, 2 Feb 2000, Andrew Apted wrote: Christoph Egger writes: Is anyone here already hacking the file-target? No, I'm pretty sure no one is working on it. If not, I want to hack it to add support reading some file-formats (i.e. bmp, tga, pcx). Go ahead, it would be good. Semantics wise, you should load the file at init time, determine the properties (width, height, depth). Then make the CheckMode primitive set any GGI_AUTO values to the same as the file, and make the SetMode refuse any mode that doesn't match the file (unless you want to support scaling/depth conversion... :-). Make all write primitives (putpixel, drawline, etc) fail, and only support the read primitives (you will only need GetPixel_NC to get an initial prototype working). Hope that helps. Yes, THX! I will do so. OK - I've started hacking on it. 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? One further question: I need an viewer using the file-target, to test it. Has anyone already one written? Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: file-target
Hi!
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.
Then I will hack on.
Christoph Egger
E-Mail: [EMAIL PROTECTED]
Binary files 2130/degas/lib/libggi/display/file/.libs/file.so and
degas/lib/libggi/display/file/.libs/file.so differ
diff -uNr 2130/degas/lib/libggi/display/file/fileio.c
degas/lib/libggi/display/file/fileio.c
--- 2130/degas/lib/libggi/display/file/fileio.c Tue Apr 13 07:07:28 1999
+++ degas/lib/libggi/display/file/fileio.c Wed Feb 2 20:44:56 2000
@@ -36,8 +36,21 @@
#include ggi/internal/ggi-dl.h
#include ggi/display/file.h
+#include ggi/system.h
+
+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 }
+};
+
+
+
+/* common primitives */
+
int _ggi_file_create_file(ggi_visual *vis, char *filename)
{
FileHook *ff = FILE_PRIV(vis);
@@ -85,6 +98,87 @@
ff-buf_len = 0;
}
+/* 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
+}
+
+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
+}
+
+void _ggi_file_read_longword(ggi_visual *vis, long *val)
+{
+#ifdef GGI_LITTLE_ENDIAN
+ _ggi_file_read_word(vis, (int*)(val) );
+ _ggi_file_read_word(vis, (int*)(val+2) );
+#else
+ _ggi_file_read_word(vis, (int*)(val+2) );
+ _ggi_file_read_word(vis, (int*)(val) );
+#endif
+}
+
+void _ggi_file_read_string(ggi_visual *vis, char *str, int strlen)
+{
+ for (; strlen 0; strlen--) {
+ _ggi_file_read_byte(vis, (int*)(str));
+ }
+}
+
+void _ggi_file_read_zeros(ggi_visual *vis, int count)
+{
+ FileHook *ff = FILE_PRIV(vis);
+
+ if ((ff-buf_len + count) = FILE_BUFFER_SIZE) {
+ count = (ff-buf_len + count) - FILE_BUFFER_SIZE;
+
+ /* FIXME: Is it that, what I should do here? */
+ }
+
+ for (; count 0; count--) {
+ ff-buffer[ff-buf_len++] = 0;
+ }
+}
+
+
+
+/* Write primitives */
+
void _ggi_file_write_byte(ggi_visual *vis, int val)
{
FileHook *ff = FILE_PRIV(vis);
@@ -99,8 +193,24 @@
void _ggi_file_write_word(ggi_visual *vis, int val)
{
+#ifdef GGI_LITTLE_ENDIAN
_ggi_file_write_byte(vis, val 8);
_ggi_file_write_byte(vis, val 0xff);
+#else
+ _ggi_file_write_byte(vis, val 0xff);
+ _ggi_file_write_byte(vis, val 8);
+#endif
+}
+
+void _ggi_file_write_longword(ggi_visual *vis, long val)
+{
+#ifdef GGI_LITTLE_ENDIAN
+ _ggi_file_write_word(vis, val 16);
+ _ggi_file_write_word(vis, val 0x);
+#else
+ _ggi_file_write_word(vis, val 0x);
+ _ggi_file_write_word(vis, val 16);
+#endif
}
void _ggi_file_write_string(ggi_visual *vis, char *str)
@@ -116,3 +226,31 @@
_ggi_file_write_byte(vis, 0);
}
}
+
+
+/* some helpers */
+
+
+/* _ggi_file_get_extension:
+ * When passed a complete filename (with or without path information)
+ * this returns a pointer to the file extension.
+ */
+char *_ggi_file_get_extension(char *filename)
+{
+ int pos, end;
+
+ pos = end = strlen(filename);
+
+ while ((pos 0)
+(filename[pos - 1] != '.')
+(filename[pos - 1] != '/')
+(filename[pos - 1] != '\0')
+(filename[pos - 1] != '#'))
+ pos--;
+
+ if (filename[pos - 1] == '.')
+ return filename + pos;
+
+ return filename + end;
+}
+
diff -uNr 2130/degas/lib/libggi/display/file/mode.c
degas/lib/libggi/display/file/mode.c
--- 2130/degas/lib/libggi/display/file/mode.c Mon Dec 13 07:10:45 1999
+++ degas/lib/libggi/display/file/mode.cWed Feb
Re: file-target
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. Cheers, __ \/ Andrew Apted [EMAIL PROTECTED]
Re: file-target
Christoph Egger writes:
One further question:
I need an viewer using the file-target, to test it.
Has anyone already one written?
There's GGV, which should be on the GGI FTP site. It would prolly be
easier though to just take one of the demos (e.g. pageflip), and put
something like this in:
file_vis = ggiOpen("display-file:/tmp/foo.ppm", NULL);
ggiSetMode(file_vis ...);
ggiCrossBlit(file_vis - normal_vis);
ggiGetc(normal_vis);
Cheers,
__
\/ Andrew Apted [EMAIL PROTECTED]
file-target
Hi! Is anyone here already hacking the file-target? If not, I want to hack it to add support reading some file-formats (i.e. bmp, tga, pcx). Christoph Egger E-Mail: [EMAIL PROTECTED] P.S.: If I don't get any response until this weekend, I assume nobody is already hacking it, and I will start...
file target problem
The file target in ggi-devel-000103 invariably segfaults if you ask the file target to write a ppm file rather than a raw file (can send more debugging info if you need it). Works fine in 2.0b2.1. The file target code is the same, so must be somewhere else. LibGGI: Disposing "generic-stubs" LibGGI: Closing handle: 0x80a3688 LibGGI: _ggiZapDL(0x808db50, 0x808edcc) called LibGGI: Disposing "generic-color" LibGGI: Closing handle: 0x80a3a38 LibGGI: _ggiZapDL(0x808db50, 0x808ee34) called LibGGI: Disposing "file" LibGGI: display-file: going down. LibGGI: display-file: GGIresetmode(0x808db50) (segv) Justin
