I never ran into myself either, I had always had access to GDI and the
numerous functions that go along with it, so I could display images a
thousand different ways, mainly I would keep arrays of the RGB colors
and use DIBs to draw them as one big image. But trying to keep my app
cross platform, limits my choices. And using individual images has
many advantages in my app such as being able to destroy select images
and keep the rest loaded, replacing the originals with new ones,
etc... FOX has enough functions that I can still do what I want,
another way, thankfully, but it would have been nice if this
limitation was noted on the FAQ or docs, I know you cant cover ever OS
nuance, but as allways when a problem poped up with a fox object, I
scoured the docs and faqs for hours trying to figure this out. I was
thinking either bad code, bad install of windows, or fox issue, the
last thing I would have ever though of was an OS limitation,
especially as low as 1023.
Also if you could make a drawArea and drawImage function that allows
you to scale them as you draw them (like Stretchblt), that would come
in very handy in the future. Just an idea. Right now I have to
create new images scaled down, per size I want.
Also another function that would come in handy, just an idea, is one
to "blt" from a FXColor array, to a FXImage, without having to create
a go between FXImage.
On Mon, 2 Aug 2004 01:39:28 -0500, jeroen <jeroen@...:
> On Sunday 01 August 2004 09:00 pm, The Devils Jester wrote:
> > On Mon, 02 Aug 2004 02:19:19 +0100, Niall Douglas
> >
> > <s_sourceforge@...> wrote:
> > > On 1 Aug 2004 at 16:43, The Devils Jester wrote:
> > > > If you do get this behavior, because of the windows limit, it would be
> > > > nice if you made a note of this somewhere, in the FAQ or similar, so
> > > > anyone in the future can read it without searching through thousands
> > > > of archived emails.
> > >
> > > It's a known limitation described in lots of places in the MSDN
> > > documentation. It would affect any toolkit, including MFC and Qt.
> > >
> > > > I cant do the create, destroy, create, destroy, etc.., because the
> > > > images are drawn many hundreds of times over and over. And during
> > > > this I have hundreds of OpenGL objects being drawn, and many other CPU
> > > > intensive operations, so every tick counts. The one big image seems
> > > > like my best bet...
> > >
> > > What you need is a LRU cache of the images in their created state. As
> > > it happens, TnFOX has one in FXLRUCache but feel free to write your
> > > own.
> > >
> > > Put simply, the LRU cache might have one hundred entries each with a
> > > timestamp of their last use. When a cache search fails, the oldest
> > > gets destroyed so that the newest can get created.
> > >
> > > You can use the one big image if you want - it's how Qt internally
> > > hacks around the GDI handle limit - but it's annoying to use plus you
> > > can run into the 32768 image size limit :)
>
> BTW, the image size is MUCH lower than 32768 x 32768. Mayby 4096x4096 or
> so. Perhaps even lower.
>
> [does anyone know exactly?]
>
> > Putting all 256 images together, would give me an image of 512x512
> > pixels, not too much to worry about. And the duplicate images would
> > form a 256x256 pixel image, so again, nothing to approch any kind of
> > limit, since I only have about two of these loaded at any one time.
>
> I believe 512x512 ought to work.
>
> But you'd better not try to load this beauty:
>
> http://photojournal.jpl.nasa.gov/jpeg/PIA04965.jpg
>
>
> > As far as the limitation goes, I have been developing windows apps for
> > many years and never knew of that limitation. Many 3rd party libs I
> > use dont assign 'windows handles' to the images, they use their own
> > internal handles, of which there can be hundreds of thousands, I had
> > assumed that fox would do the same thing and only use windows handles
> > upon request. Also, not everyone studies the MSDN, not everyone even
> > uses windows. My case for instance. I use linux, and develop my app
> > in linux, test it in linux, yet make sure I use no os dependant calls
> > so that it can compile and run in windows as well. Id rather drop
> > support for windows entirely than spend months reading the MSDN for
> > information that I wont use for much of anything because I dont use or
> > develop in windows. So its not to much to ask to just make a simple
> > note of this in the FAQ.
> >
> > I dont mind doing it another way, but it would have been nice if this
> > limitation, even though its not fox specific, was mentioned in the FAQ
> > or FXImage docs, etc..., a simple sentence that could save many hours
> > of debuging. When an FX object fails to create, the first place most
> > will look is in the FOX docs, not MSDN.
>
>
> Point taken; I'll add some note to the FAQ about it. I've just never
> ran into it myself, even though I've been writing some pretty icon-rich
> applications.
>
> Perhaps the problem is more acute on Windows 9x...
>
> - Jeroen
>
> --
> +----------------------------------------------------------------------------+
> | Copyright (C) 01:20 08/ 2/2004 Jeroen van der Zijp. All Rights Reserved. |
> +----------------------------------------------------------------------------+
>
>
--
Talent is not something you learn, its something you refine.
If you make something that any idiot can use, only idiots will use it.
|