nanogui: Thread: loading images from memory


[<<] [<] Page 1 of 1 [>] [>>]
Subject: loading images from memory
From: "David Erickson" ####@####.####
Date: 2 Jan 2002 18:03:22 -0000
Message-Id: <200201021800.KAA04954@mon-irva-11.broadcom.com>

Is there any plan to support loading images from memory instead of just disk? 
I see in the jpeg and png code the file pointer is being passed to the 
library calls.

How about using fmemopen() in something like:
GdLoadImageFromMemory(PSD psd, const char *mem, int len, int flags)

I've never used fmemopen, and I have no man page for it, but I saw it in my 
/usr/include/stdio.h file. Is it standard?

-- 
David Erickson
Senior Staff Software Engineer
Broadcom Corporation
949-585-5875

Subject: RE: [nanogui] loading images from memory
From: Peter Kerr ####@####.####
Date: 2 Jan 2002 18:07:49 -0000
Message-Id: <E431D83CC68B384AA06257848A5D6DAA02DFAF@Z_MAIL.zeacomus.com>

Is this not achieved with GrLoadImageFromFile?

Peter Kerr

-----Original Message-----
From: David Erickson ####@####.####
Sent: Wednesday, January 02, 2002 10:08 AM
To: ####@####.####
Subject: [nanogui] loading images from memory


Is there any plan to support loading images from memory instead of just
disk? 
I see in the jpeg and png code the file pointer is being passed to the 
library calls.

How about using fmemopen() in something like:
GdLoadImageFromMemory(PSD psd, const char *mem, int len, int flags)

I've never used fmemopen, and I have no man page for it, but I saw it in my 
/usr/include/stdio.h file. Is it standard?

-- 
David Erickson
Senior Staff Software Engineer
Broadcom Corporation
949-585-5875


---------------------------------------------------------------------
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail: ####@####.####
Subject: Re: [nanogui] loading images from memory
From: Jordan Crouse ####@####.####
Date: 2 Jan 2002 18:13:45 -0000
Message-Id: <E16Lpre-000444-00@ns.censoft.com>

We do have such a beast in pre8 - Its called GrLoadImageFromBuffer() and 
GrDrawImageFromBuffer().  

The only thing that we are currently missing is a native way to handle 
compiled in XPMs.  If the list agrees, I may break the existing XPM support 
by changing the internal decoder to use XPM data (ie, the actual char array), 
instead of an XPM file.  Then, we could add a client side function to decide 
an actual XPM file and send across the data.  I know Julian would like this, 
but is there anyone who really uses the current XPM support and would get 
angry if I borked it?

Jordan

On Wednesday 02 January 2002 11:08, David Erickson mentioned:
> Is there any plan to support loading images from memory instead of just
> disk? I see in the jpeg and png code the file pointer is being passed to
> the library calls.
>
> How about using fmemopen() in something like:
> GdLoadImageFromMemory(PSD psd, const char *mem, int len, int flags)
>
> I've never used fmemopen, and I have no man page for it, but I saw it in my
> /usr/include/stdio.h file. Is it standard?
Subject: Re: [nanogui] loading images from memory
From: Julian Smart ####@####.####
Date: 2 Jan 2002 18:25:25 -0000
Message-Id: <4.2.0.58.20020102182031.05f1aaf0@pop>

At 11:07 AM 1/2/02 -0700, Jordan Crouse wrote:
 >We do have such a beast in pre8 - Its called GrLoadImageFromBuffer() and 
 >GrDrawImageFromBuffer().  
 >
 >The only thing that we are currently missing is a native way to handle 
 >compiled in XPMs.  If the list agrees, I may break the existing XPM support 
 >by changing the internal decoder to use XPM data (ie, the actual char array), 
 >instead of an XPM file.  Then, we could add a client side function to decide 
 >an actual XPM file and send across the data.  I know Julian would like this, 
 >but is there anyone who really uses the current XPM support and would get 
 >angry if I borked it?

Actually I discovered how to (partially) work around it -- wxWindows now has its own,
self-contained XPM decoder, and I'm using this for loading XPM data into a wxImage,
and then using a very dumb piece of code to copy the wxImage to a wxBitmap which
can be drawn onto device contexts.

However, I expect the official MicroWindows API will be a more efficient way to
load XPM data into [wx]Bitmaps more directly.

BTW if anyone knows how to do transparency in MicroWindows (WIN32) using a bitmap
and a mask bitmap, that would be interesting. When I created a mono bitmap and
used that in BitBlt as per normal WIN32 code, MicroWindows complains about the depth
not being suitable for the DC. When I create the mask at the display depth instead, the
operations that work for 'real' WIN32 to do transparency, don't work under MicroWindows.

Thanks,

Julian
-- 
Red Hat UK Ltd, Unit 200 Rustat House, 62 Clifton Road, Cambridge, UK. CB1 7EG Tel: +44 (1223) 271063
Subject: Re: [nanogui] loading images from memory
From: Jordan Crouse ####@####.####
Date: 2 Jan 2002 18:42:21 -0000
Message-Id: <E16LqJJ-0004E5-00@ns.censoft.com>

> BTW if anyone knows how to do transparency in MicroWindows (WIN32) using a
> bitmap and a mask bitmap, that would be interesting. When I created a mono
> bitmap and used that in BitBlt as per normal WIN32 code, MicroWindows
> complains about the depth not being suitable for the DC. When I create the
> mask at the display depth instead, the operations that work for 'real'
> WIN32 to do transparency, don't work under MicroWindows.

Funny you should mention that, we have been telling Greg that we need to have 
variable depth pixmaps for a while now.  

It wouldn't be *too* messy, the only thing we would need is a set of really 
good conversion blit routines (especially to and from a depth of 1 (for 
bitmaps)).  If anyone has any that they have been working on and want to 
donate to the cause, we can write all the supporting code pretty quickly.

Jordan

On Wednesday 02 January 2002 11:26, Julian Smart mentioned:
> At 11:07 AM 1/2/02 -0700, Jordan Crouse wrote:
>  >We do have such a beast in pre8 - Its called GrLoadImageFromBuffer() and
>  >GrDrawImageFromBuffer().
>  >
>  >The only thing that we are currently missing is a native way to handle
>  >compiled in XPMs.  If the list agrees, I may break the existing XPM
>  > support by changing the internal decoder to use XPM data (ie, the actual
>  > char array), instead of an XPM file.  Then, we could add a client side
>  > function to decide an actual XPM file and send across the data.  I know
>  > Julian would like this, but is there anyone who really uses the current
>  > XPM support and would get angry if I borked it?
>
> Actually I discovered how to (partially) work around it -- wxWindows now
> has its own, self-contained XPM decoder, and I'm using this for loading XPM
> data into a wxImage, and then using a very dumb piece of code to copy the
> wxImage to a wxBitmap which can be drawn onto device contexts.
>
> However, I expect the official MicroWindows API will be a more efficient
> way to load XPM data into [wx]Bitmaps more directly.
>

>
> Thanks,
>
> Julian
Subject: Re: [nanogui] loading images from memory
From: Chris Ross ####@####.####
Date: 2 Jan 2002 19:22:24 -0000
Message-Id: <20020102192014.A10294@darkrock.co.uk>

On Wed, Jan 02, 2002 at 11:36:29AM -0700, Jordan Crouse muttered...
: > BTW if anyone knows how to do transparency in MicroWindows (WIN32) using a
: > bitmap and a mask bitmap, that would be interesting. When I created a mono
: > bitmap and used that in BitBlt as per normal WIN32 code, MicroWindows
: > complains about the depth not being suitable for the DC. When I create the
: > mask at the display depth instead, the operations that work for 'real'
: > WIN32 to do transparency, don't work under MicroWindows.
: 
: Funny you should mention that, we have been telling Greg that we need to have 
: variable depth pixmaps for a while now.  
: 
: It wouldn't be *too* messy, the only thing we would need is a set of really 
: good conversion blit routines (especially to and from a depth of 1 (for 
: bitmaps)).  If anyone has any that they have been working on and want to 
: donate to the cause, we can write all the supporting code pretty quickly.

It might be worth digging around in Imlib2 - there are routines in there to
do all sorts of image depth conversions, I would elaborate futher but I dont
have a copy to hand. But I know Carsten (raster) has got all sorts of *fast*
routines in there that may be a good base point. I will also talk to raster
as I know he has some stuff in the pipeline,

regards,

Chris
-- 
Chris Ross (boris)      ####@####.#### |       ####@####.####
                   http://www.darkrock.co.uk |  http://www.ferite.org
        "I dont suffer from insanity - I enjoy every minute of it..."
[<<] [<] Page 1 of 1 [>] [>>]


Powered by ezmlm-browse 0.20.