discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bitmap objects


From: Willem Rein Oudshoorn
Subject: Re: Bitmap objects
Date: 28 Jan 2002 22:05:19 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1

Pete French <pete@twisted.org.uk> writes:

> Having looked through the code the actual display is done by DPSimage
> which takes the data and copies it to the screen. This assumes 8 bit
> samples, and does not handle planar data. I am not really up
> for changing the interface to DPSimage, so my intial thought is that if
> a bitmap of non 8 bit samples is required to be rendered then it can be
> upconverted to an 8 bit image inside the NSBitmapImageRep "draw" method
> and then the resulting data passed to DPSimage.

Actually, I would change the xgps code.  It is not necessary to change the
interface of the DPSimage method.

Little disclaimer, I am just reading the source code and the postscript language
reference  manual.  So I might get some subtle points wrong.


xgps                          postscript
     
DPSimage                      image (altenative form API wise)

The documentation of image/color-image specifies the following arguments:


postscript                                         xgps

width       (width in sample pixels)               Width
height      (height in sample pixels)              Height
bits/comp   (1, 2, 4, 8 or 12)                     BitsPerComponent
matrix                                             -- 
datasrc0                                           DataSource (*4)
...                                                -- 
datasrc{n-1} (*)                                   -- 
multi       (false or true)                        MultipleDataSources (**)
ncomp       (1, 3 or 4)                            SamplesPerPixel
--(*3)                                             Alpha

(*) the number of data sources is
    - equal to ncomp if multi is true
    - equal to 1 if multi is false.  In this case the image 
      data is stored interleaved in datasrc0.

(**) xgps at the moment only supports multi == false
(*3) not in the postscript language reference manual
(*4) DataSource contains either:
     an object responding to cString, in this case we have a single
          data source whose contents is this cString.
     an object responding to pointerValue.  In this case the pointerValue
     is of type `char **' so this takes care of the the multiple data source.


This means that you can already pass all the data you want.  The only thing 
is that the data is not passed to the function:

_bitmap_combine_alpha

So probably if you just add the correct argument to _bitmap_combine_alpha
and use it, it should work.


> The downside of this is the speed as the conversion needs to be done
> every time the image is drawn (as the mage data can be manipulated directly in
> memory and another raw method sent then I cannot cache the results). On the
> upside, however, it is not much more effort to resize the bitmap at the
> same time asdoing this conversion - thus enabling the drawInRect method
> to work correctly and arbitrarily scale the image. I am assuming there is some
> way of detecting the backend in useso  that I dont have to do this forthe
> DGS backend where image scaling should preseuably work in the normal way?

Well, I think scaling might also be done in the backend.  But here I am 
actually not so sure.  Now lets look at the NeXT reference manual to 
to make things even more confusing.  

The documentation of the postscript operator `image' in the 
NeXTstep general reference manual volume two indicates
that the dictionary argument to the image operator are:

NeXT `image'      type          value

ImageType         integer       always 2
XOrigin           float         Origin of the source rectangle (User space)
YOrigin            ,,
Width              ,,           Size of the source  (User space)
Height             ,,
ImageMatrix       array        
DataSource        gstate        containing pixels, color values 
                                transformation matrix etc.
Interpolate       boolean
UnpaintedPath      ??           Is a return value indicated the area 
                                that is not painted due to clipping
PixelCopy         boolean       Skip all the expensive calculations.



NeXT `alphaimage'  correspond to the `colorimage' operation of Postscript.

In short:


PS L1               PS L2               NeXT                     xgps

colorimage          image               alphaimage               DPSimage
  uses explicit       uses dict.          same                     more or
  arguments           encompasses         as colorimage            less the 
                      L1 colorimage       except,                  same as
                                          ncolors is off           PS L2 imge
                                          by one.
                                          and includes
                                          always alpha channel


Besides these the NeXT `image' operator seems a little bit strange.  It does
quite something different.


This is a long story, I hope that there is someone with either more
up to date reference manuals or a better insight in the design decisions
behind xgps what the xgps DPSimage operator actually is supposed to do.

Hope this helps,

Wim Oudshoorn.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]