🚀 go-pugleaf

In article <1992Apr7.155202.18548@talus.com> ajamison@talus.ogi.edu writes:
>In article <3502@rosie.NeXT.COM> aozer@next.com (Ali Ozer) writes:
>> done that, the problem goes away. Your bug sounds like that problem, and if
>> they're the same, then, yes, it's a NXImage bug, and it's fixed in 3.0. 
>Yeah, right.  Will they fix the lockFocus as well, or maybe the Bitmap  
>rendering, or maybe the screen rendering, or maybe the fact that the NXImage  
>object is too slow to render most images. ...
>I had to re-write the NXImage object because NeXT didn't do it right the first  
>time, the damn thing is too slow rendering and god forbid you actually want to  
>make a bitmap of anything at any size.  It's great if you want to render an  
>image that is only, say, 512k x 360k.  Now, let me ask you this, have you tried
>rendering, let alone locking focus on, a 2k x 2k image that has 700 dpi worth  
>of data?  Takes a bit of time eh?

Let's take the image you describe --- 2k x 2k, 700dpi. Assume it's 24
bits deep.  Drag it into your average application (Draw, Mail, Diagram,
you choose...). The image takes 20 seconds to render on the NextStation
Color, 25 seconds on the ND, and 15 seconds on a monochrome
NextStation. Then you can drag it around in the app at full speed,
with no wait.  If you resize it right after dropping it, it resizes in
less than half the time shown above. Wait a bit before resizing, and
resizing might take as much time as the initial drop. Etc.

These are perfectly reasonable numbers --- after all, the image
contains 12 megabytes of data.  You will get these reasonable results in
most ordinary uses of NXImage. Majority of applications just want to
be able to import and display images, and NXImage was designed mainly
for that --- to allow apps to use images in their UI or to allow apps to
import images from users, all with a minimum of code. Under 3.0,
if the user has the appropriate filters, applications using NXImage
can even import other image types with minimal (in some cases no)
change. NXImage also provides the ability to specify or automatically
import multiple representations so that the application developer doesn't
have to worry about choosing between different images on different devices.
This again comes back to letting developers use images with minimal effort.

The scenario you're describing is one where you need the image to be
rendered pixel by pixel into a buffer. The application is most
probably one of paint or image touch-up.  An application using NXImage for this
purpose will have to render the above 2k x 2k image into a 2k x 2k cache; this
operation will end up creating a 12 megabyte cache to render the image in.
On most machines with normal amount of memory, this operation will cause much 
swapping, and you might indeed wait a long time for the operation to 
complete. For instance, Icon (or Pixelist) both keep around 3 buffers, and a 
16 meg machine takes minutes to load that image into these buffers.

But here you're looking at an application which NXImage wasn't designed
or meant for. It has no API to help you out (say, for instance, by
tiling the image), just like it doesn't have most other features which
most image retouching applications need (such as changing image
depth/configuration, providing dithering or scaling options better
than PostScript's, etc).  In keeping with the tradition of making simple
things real easy, we end up with the class we have. With more resources 
and time, NeXTstep could include API/classes/library to allow dealing
with huge images on a pixel-by-pixel basis efficiently; however, given that
it's not there currently, it's up to third parties, basically folks like 
you, to make it happen and enable that class of application.

Anyway, I'd certainly be interested in hearing what your class does more
efficiently, and, if you're willing to share the info, how it does it.

Ali, Ali_Ozer@NeXT.com