DIB_BLOCK limits

I am trying to use the DIB_BLOCK subroutines to generate JPG files, but I seem to have encountered a size limitation. No problem with images up to 2048 x 2048 pixels, but larger than this, although I have (so far) found no limit in the vertical (Y) direction, anything beyond 2048 pixels in the X direction displays as black. So how do I generate a 4096 x 4096 image? Is the 2048 horizontal extent an absolute limitation of the CREATE_GRAPHICS_REGION@ function?

I'm using CLEAR_SCREEN_AREA@, GRAPHICS_WRITE_MODE@, and multiple calls to DRAW_LINE@, to generate the graphics, then RECOVER_DIB_BLOCK@ and PUT_DIB_BLOCK@ to write the JPEG file. I tried with a .BMP file but found exactly the same 2048 pixels limit in the x direction.

If you will put this into a short sample program, I will see if I can find any limitation within the library.

Hi, Paul - Many thanks for the offer. I've extracted the following (fixed-format fortran) from my code and it shows the problem:

  winapp 'resource.rc'
  program testplot
  use mswin
  INTEGER WVM,HVM,VMHANDLE,FUNC,ICOLR
  CHARACTER*1 PARRAY(3,4000,4000)
  WVM = 4000
  HVM = 4000
  IOPEN = CREATE_GRAPHICS_REGION@( VMHANDLE,WVM,HVM )
  ierr = select_graphics_object@(VMHANDLE)
  call use_rgb_colours@ (VMHANDLE,1)
  ICOLR = RGB@(255,255,255)
  call draw_filled_rectangle@ (0,0,WVM,HVM,ICOLR)
  ICOLR = RGB@(127,127,127)
  call draw_filled_rectangle@ (500,500,3500,3500,ICOLR)
  call graphics_write_mode@ (1)
  ICOLR = RGB@(0,0,255)
  call draw_line@ (200,200,200,3800,icolr)
  call draw_line@ (200,3800,3800,3800,icolr)
  call draw_line@ (3800,3800,3800,200,icolr)
  call draw_line@ (3800,200,200,200,icolr)
  ICOLR = RGB@(255,255,0)
  call draw_line@ (3000,1000,1000,3000,icolr)
  call draw_line@ (1000,1000,3000,3000,icolr)
  ICOLR = RGB@(127,127,0)
  call draw_filled_rectangle@ (1500,1500,2500,2500,ICOLR)
  FUNC = 0
  MODE = 0
  IX = 0
  IY = 0
  call RECOVER_DIB_BLOCK@(IX,IY,PARRAY,WVM,HVM,IX,IY,WVM,HVM,
 1                          FUNC,MODE,IERCODE )
  call PUT_DIB_BLOCK@( 'test.jpg',PARRAY,WVM,HVM,IX,
 1                      IY,WVM,HVM,NBPP,IERCODE )
  stop
  end 

One odd thing I noticed - when compiling and linking this on its own it occupies 47 megabytes, yet when I use the same coding within a big and complex application the size is only 1.3 megabytes. The complex application has PARRAY etc in a common block - so would that explain the difference?

I have also noted limits on the size of windows that can be used, but I thought it was greater than you have found.

An alternative approach that I use, not using DIB, is to dump the active window direct to file, using either:

      call write_graphics_to_pcx@ (file_pcx, error_pcx)  ! .pcx file
      error_jpg = export_image@ (file_jpg)               ! .jpg file
      call write_graphics_to_gif@ (file_gif, error_gif)  ! .gif file

I create and select my virtual screen using the following:

     INTEGER*4, PARAMETER :: MXZBUF = 1024*3      ! virtual screen buffer limits

      subroutine set_virtual_screen_size
!
!    Sets the dimensions for the %gr screen, including menu and border
!
      INCLUDE 'crtcom.ins'
      include <clearwin.ins>
      include <JDC_menu.ins>
      integer*4 i
!
      write (98,9000) 'Setting Virtual Screen Size'
      write (98,9000) 'Old graphics size     ', w_width, w_depth
!
      call get_graphical_resolution@ ( w_width, w_depth )
      write (98,9000) 'Returned graphics size', w_width, w_depth
      write (98,9000) 'PC Screen Size        ', s_width, s_depth
!
      HDFLAG        = ABS (HDFLAG)
      NXPIX         = MIN (HDFLAG,MXZBUF)      ! limit for zbuffer
      NXPIX         = MAX (NXPIX, W_WIDTH)     ! not too small
!
!    real units for tek units to pixel conversion : retain aspect ratio
      X_MAX_WIN     = nxpix - 1
      Y_MAX_WIN     = X_MAX_WIN * ASPECT_WIN
      NYPIX         = Y_MAX_WIN + 1
      NYPIX         = MIN (NYPIX, MYZBUF)      ! limit for zbuffer
      X_MIN_WIN     = 0
      Y_MIN_WIN     = 0
!
      W_WIDTH       = NXPIX                    ! window width
      W_DEPTH       = NYPIX                    ! window depth less menu
      write (98,9000) 'Revised graphics size ', w_width, w_depth
!
      i = create_graphics_region@ (hd_handle, w_width, w_depth)
      i = select_graphics_object@ (hd_handle)
!
      call draw_filled_rectangle@ (0,0, w_width-1,w_depth-1, rgb@ (50,50,50))
!
9000  FORMAT ('<VIRTIAL_SCREEN> :',a,' X=',I4,' Y=',I4)
!
      end subroutine set_virtual_screen_size

I see my parameter settings have not tested 4096. It would be good to find where this limit does exist and allow larger files.

John

Hi, John - Many thanks for these suggestions.

Everything has to be done as 'virtual' screens, not real graphics windows, because it's a web application so that all output must go to files, not to a physical screen. ASP coding in the webpage then spools the transcript file to the user in a dynamic webpage, and provides a link to the generated jpeg file.

Have tried the export_image route with jpeg format, still the same limit, 2048 pixels in the x direction. Also, even on highest JPG quality the image is much worse than going via the DIB_BLOCK route.

PCX and BMP images come out with the same 2048 pixels limit in the x direction. The files are both enormous (and exactly the same size), but BMP image quality is better.

Conclusion - the limit is nothing to do with how the graphics are exported, but seems to be an internal storage liimit.

Question... I am using F95 version 3.0 - is this possibly a known bug that may have been fixed in a later version? I'm not willing to try and install the free personal F95 over the licensed 3.0 - I've done this before and had problems getting back to the licensed version. However, if I can be assured that the problem is fixed in the latest version, then willing to buy an upgrade.

Another thought. Much (most) of what I am doing is conversion of old vector-plotting programs, with some filled rectangles, some text, but not a lot else, so perhaps the SVG format is more appropriate. Will experiment a little with this. Any ideas on a suitable (ideally free!) SVG library?

There have been changes that could affect the result.

Try downloading the personal edition to a different machine and then copy salflibc,dll across (making sure to keep a copy of the old dll).

Hi, Paul - many thanks for the suggestion: will try this.

I have also experimented with SVG and that also seems to work, though it needs a bit more programming. Huge advantage that it's an XML format so can do the whole thing as simple writes to a file. However, the optimum will be to give users the choice of JPG or SVG formats.

I have changed to using .gif files. They appear to offer advantages compared to .jpg, especially for scientific or vector images. I did use .pcx, until it's support in windows reduced. John

I have implemented an SVG solution which seems to work just fine. Neither PCX nor BMP is suitable for web applications. SVG has the huge advantage that being XML it can use ordinary Fortran writes. I started from the coding by Fabio Pietrucci (http://sites.google.com/site/fabiopietrucci/Home/downloads) which does all I need.

As for the JPG version, I tried the new version of salflibc.dll with the JPG coding and hit exactly the same limit. Wondering now whether this is actually a memory limit: my development machine is an old computer running Windows 2000 (nice and stable) but with just 512M memory. However, I haven't hit any memory limits elsewhere and would be a little surprised if it were constrained by such a limit without giving any error messages.

I shall now try GIF, but expect that it will have just the same problem (as with JPG, BMP, and PCX) because it seems not to be a function of the output format but the PARRAY graphics area itself.

Steve,

I've updated your example so that different values of WVM (x_max) can be more easily tested. The example does confirm your problem and I did not find any problem with your code, except for my interpretation of the PARRAY offsets, which I am probably wrong. I think you should provide a value of VMHANDLE. As PARRAY is not being used in the code, I'd expect it can be dimensioned to anything large enough. All error responses indicate success at each call.

!winapp 'resource.rc' 
 program testplot 
 use mswin 
!
 integer*4, parameter :: x_max = 3000 ! 2048 works
 integer*4, parameter :: y_max = 4000 ! extended is ok
!
 INTEGER WVM,HVM,VMHANDLE,FUNC,ICOLR,  x,y,IX,IY,MODE,IERCODE,NBPP, iopen,ierr
 CHARACTER*1 PARRAY(3,x_max,y_max) 
!
 vmhandle = 11
 WVM = x_max
 HVM = y_max
 IOPEN = CREATE_GRAPHICS_REGION@ ( VMHANDLE,WVM,HVM ) 
 write (*,*) 'CREATE_GRAPHICS_REGION@ ( VMHANDLE,WVM,HVM ) =', iopen,' (1=success)'
!
 ierr  = select_graphics_object@ ( VMHANDLE) 
 write (*,*) 'select_graphics_object@ ( VMHANDLE) =', ierr,' (1=success)'
!
 call use_rgb_colours@ (VMHANDLE, 1) 
!
 ICOLR = RGB@ (255,255,255) 
 call draw_filled_rectangle@ (0,0,WVM,HVM,ICOLR) 
!
 FUNC = 0 
 MODE = 0 
 x    = 0
 y    = 0
 IX   = 1
 IY   = 1
 call RECOVER_DIB_BLOCK@ (X,Y,             & ! location on current graphics device (0,0)
                          PARRAY,WVM,HVM,  & ! PARRAY array size
                          IX,IY,           & ! location in PARRAY (1,1,1) ??
                          WVM,HVM,         & ! block size to transfer
                          FUNC,            & ! 0 = REPLACE former pixel
                          MODE,            & ! the dib palette should be used
                          IERCODE )          ! error code
 write (*,*) 'RECOVER_DIB_BLOCK@ =',IERCODE,' (0=success)'
!
 NBPP = 24
 call PUT_DIB_BLOCK@ ( 'blank_canvas.jpg',PARRAY,WVM,HVM, X,Y, WVM,HVM, NBPP,IERCODE )  
 write (*,*) 'PUT_DIB_BLOCK@ =',IERCODE,' (0=success)'
!
 ICOLR = RGB@ (127,127,127)  ! dark grey box
 ix = x_max/8
 iy = y_max/8
 call draw_filled_rectangle@ (ix, iy, x_max-ix, y_max-iy, ICOLR)
!
 call graphics_write_mode@ (1) 
 ICOLR = RGB@ (0,0,255)      ! blue border
 ix = x_max/20
 iy = y_max/20
 call draw_line@ (      ix,       iy,       ix, y_max-iy, icolr)
 call draw_line@ (      ix, y_max-iy, x_max-ix, y_max-iy, icolr) 
 call draw_line@ (x_max-ix, y_max-iy, x_max-ix,       iy, icolr) 
 call draw_line@ (x_max-ix,       iy,       ix,       iy, icolr) 
!
 ICOLR = RGB@ (255,255,0)    ! bright red/green X
 ix = x_max/4
 iy = y_max/4
 call draw_line@ (x_max-ix,       iy,       ix, y_max-iy, icolr) 
 call draw_line@ (      ix,       iy, x_max-ix, y_max-iy, icolr) 
!
 ICOLR = RGB@ (127,127,0)    ! dull red/green box
 ix = 3*x_max/8
 iy = 3*y_max/8
 call draw_filled_rectangle@ (ix, iy, x_max-ix, y_max-iy, ICOLR) 
!
 FUNC = 0 
 MODE = 0 
 IX = 1
 IY = 1 
 call RECOVER_DIB_BLOCK@ (X,Y,PARRAY,WVM,HVM, IX,IY,WVM,HVM, FUNC,MODE,IERCODE ) 
 write (*,*) 'RECOVER_DIB_BLOCK@ =',IERCODE,' (0=success)'
!
 NBPP = 24
 call PUT_DIB_BLOCK@ ( 'test_02.jpg',PARRAY,WVM,HVM, X,Y,WVM,HVM,NBPP,IERCODE )  
 write (*,*) 'PUT_DIB_BLOCK@ =',IERCODE,' (0=success)'
!
 stop 
end 

Perhaps someone else can see the problem ?

Many thanks for the reworking, John. Will keep on chipping away at this one. I guess the next is to try the executables on computers with different memory sizes, though if you've tried it and reproduced the error that box is probably already ticked. By the way, not sure what you mean by PARRAY not being used in the code - I thought this was the array that actually held the graphics area data, and so is used by the DIB_BLOCK subroutines. Maybe I misunderstood.

By the way, the SVG version is now working smoothly, and neatly complements another program I have, which exports 3D data as VRML2format .wrl files.

Steve,

When I said 'As PARRAY is not being used in the code' I meant to say the dimension of PARRAY. It could also have been declared integer*4 PARRAY(12000000), which is about 48 mb, as it's dimensions are not being used.

Another thought is that clearwin+ imposes a drawing limit on the drawing surface. I can't recall the routine to change the drawing limit. Although we can select a drawing surface with X > 2048, there may be a limit on X to 2048 for drawing. I need to find this routine.

John

I tried a direct export of the graphics surface to a .gif file and it appears to work. This may be a good solution. I also tested PARRAY for colours, indicating not being set when X > 2048 I think there is a problem with the dimension (X limit) of the DIB interface. Try this alternative:

!winapp 'resource.rc' 
 program testplot 
! use mswin 
     include <clearwin.ins>
!
    C_EXTERNAL WRITE_GRAPHICS_TO_GIF@ '__write_graphics_to_gif' (INSTRING,REF)
!
 integer*4, parameter :: x_max = 3000 ! 2048 works
 integer*4, parameter :: y_max = 3000 ! extended is ok
!
 INTEGER WVM,HVM,VMHANDLE,FUNC,ICOLR,  x,y,IX,IY,MODE,IERCODE,NBPP, iopen,ierr
 CHARACTER*1 PARRAY(3,x_max,y_max) 
!
 vmhandle = 11
 WVM = x_max
 HVM = y_max
 IOPEN = CREATE_GRAPHICS_REGION@ ( VMHANDLE,WVM,HVM ) 
 write (*,*) 'CREATE_GRAPHICS_REGION@ ( VMHANDLE,WVM,HVM ) =', iopen,' (1=success)'
!
 ierr  = select_graphics_object@ ( VMHANDLE) 
 write (*,*) 'select_graphics_object@ ( VMHANDLE) =', ierr,' (1=success)'
!
 call use_rgb_colours@ (VMHANDLE, 1) 
!
 ICOLR = RGB@ (255,255,255) 
 call draw_filled_rectangle@ (0,0,WVM,HVM,ICOLR) 
!
      call write_graphics_to_gif@ ('blank_canvas.gif', iercode)
      write (*,*) 'write_graphics_to_gif@ =',IERCODE,' (0=success)'
!
 FUNC = 0 
 MODE = 0 
 x    = 0
 y    = 0
 IX   = 0
 IY   = 0
 call RECOVER_DIB_BLOCK@ (X,Y,             & ! location on current graphics device (0,0)
                          PARRAY,WVM,HVM,  & ! PARRAY array size
                          IX,IY,           & ! location in PARRAY (1,1,1) ??; offset
                          WVM,HVM,         & ! block size to transfer
                          FUNC,            & ! 0 = REPLACE former pixel
                          MODE,            & ! the dib palette should be used
                          IERCODE )          ! error code
 write (*,*) 'RECOVER_DIB_BLOCK@ =',IERCODE,' (0=success)'
!
 call test_DIB (PARRAY,WVM,HVM) 
!
 NBPP = 24
 call PUT_DIB_BLOCK@ ( 'blank_canvas.jpg',PARRAY,WVM,HVM, X,Y, WVM,HVM, NBPP,IERCODE )  
 write (*,*) 'PUT_DIB_BLOCK@ =',IERCODE,' (0=success)'
!
 ICOLR = RGB@ (127,127,127)  ! dark grey box
 ix = x_max/8
 iy = y_max/8
 call draw_filled_rectangle@ (ix, iy, x_max-ix, y_max-iy, ICOLR)
!
 call graphics_write_mode@ (1) 
 ICOLR = RGB@ (0,0,255)      ! blue border
 ix = x_max/20
 iy = y_max/20
 call draw_line@ (      ix,       iy,       ix, y_max-iy, icolr)
 call draw_line@ (      ix, y_max-iy, x_max-ix, y_max-iy, icolr) 
 call draw_line@ (x_max-ix, y_max-iy, x_max-ix,       iy, icolr) 
 call draw_line@ (x_max-ix,       iy,       ix,       iy, icolr) 
!
 ICOLR = RGB@ (255,255,0)    ! bright red/green X
 ix = x_max/4
 iy = y_max/4
 call draw_line@ (x_max-ix,       iy,       ix, y_max-iy, icolr) 
 call draw_line@ (      ix,       iy, x_max-ix, y_max-iy, icolr) 
!
 ICOLR = RGB@ (127,127,0)    ! dull red/green box
 ix = 3*x_max/8
 iy = 3*y_max/8
 call draw_filled_rectangle@ (ix, iy, x_max-ix, y_max-iy, ICOLR) 
!
      call write_graphics_to_gif@ ('test_02.gif', iercode)
      write (*,*) 'write_graphics_to_gif@ =',IERCODE,' (0=success)'
!
 FUNC = 0 
 MODE = 0 
 IX   = 0
 IY   = 0
 call RECOVER_DIB_BLOCK@ (X,Y,PARRAY,WVM,HVM, IX,IY,WVM,HVM, FUNC,MODE,IERCODE ) 
 write (*,*) 'RECOVER_DIB_BLOCK@ =',IERCODE,' (0=success)'
!
 call test_DIB (PARRAY,WVM,HVM) 
!
 NBPP = 24
 call PUT_DIB_BLOCK@ ( 'test_02.jpg',PARRAY,WVM,HVM, X,Y,WVM,HVM,NBPP,IERCODE )  
 write (*,*) 'PUT_DIB_BLOCK@ =',IERCODE,' (0=success)'
!
 stop 
end 

... The test routine (we need a better forum post limit)

subroutine test_DIB (PARRAY,WVM,HVM) 
!
!  tests PARRAY, showing values not set for X > 2048
!
 integer*4 WVM,HVM
 CHARACTER*1 PARRAY(3,WVM,HVM) 
 character*1 colour_list(3,11)
 integer*4 i,j,k,n,ncol, count_list(2,11)
!
ncol = 0
do i = 1,wvm
  do j = 1,hvm
!    
    do n = 1,ncol
      do k=1,3
        if (parray(k,i,j) /= colour_list(k,n)) exit
      end do
      if (k > 3) then
        k = 1 ; if (i>2048) k=2
        count_list(k,n) = count_list(k,n) + 1
        exit
      end if
    end do
!    
    if (n > ncol) then
      if (ncol < 11) then
        ncol = ncol+1
        colour_list(:,n) = parray(:,i,j)
        count_list(:,ncol) = 0
      end if
      n = ncol
      k = 1 ; if (i>2048) k=2
      count_list(k,n) = count_list(k,n) + 1
    end if
!   
  end do
end do
!
write (*,*) ' '
write (*,*) 'Colour analysis for DIB'
write (*,*) wvm,hvm, ' dimensions'
write (*,*) ncol, ' colours found'
do n = 1,ncol
  write (*,*) n, count_list(:,n), (ichar(colour_list(k,n)),k=1,3)
end do
write (*,*) ' '
end

I have struck this X limit previously, but have forgotten when it could occur. Hopefully it is limited to DIB. I am about to test larger virtual windows on newer PC's, so hopefully I'll know what to expect.

.gif appears to be a very good format for scientific displays. It is compact and there are not the distortion problems of .jpg. There are some limitations with .gif, limited to 256 active colours being the main feature. Robert is presently helping with providing improved functionality with selecting the active colour palette.

John

Thank you very much indeed for all this help, John! It never ceases to amaze me how helpful the Fortran community is.

I agree about the preference for GIF. A 256-colour palette is not a problem for me, as it's a considerable expansion on the 16 and 64 colour palettes that my 'legacy' applications have been limited to in the past.

This post has highlighted to me that DIB is another option for updating the active graphics window. I have developed my own hidden line shading, based on the pixel depth. To update the active window, in the past, I have:

1. Started with Draw_point@ to update the pixel colour and get_RGB_Value@ to get the pixel colour of the active window.

2. I moved from draw_point@ to draw_line_between@ to improve the update rates.

3. Recently I have started to introduced user_surface into “winio@ ('%`^gr grey, user_resize, rgb_colours, full_mouse_input, user_surface]&'” to allow direct addressing of the graphics surface. I have not fully tested this option.

4. DIB offers a way of retrieving or setting the RGB colours for the active screen, using a single call, presumably much quicker than draw_point@ but possibly slower than direct addressing. It clearly can access any virtual graphics surface. Any size can be managed when character*1 PARRAY(3,mx,my) is declared allocatable. User_surface has the advantage of direct addressing of the graphics information. The pointer changes value with a window resize and (I hope) with calls to select_graphics_object@ (is this the case ?). It has the disadvantage of a more complex addressing method, as in:

     integer*4 rgb_i(3)
     iw = clearwin_info@ ('GRAPHICS_WIDTH')
     id = clearwin_info@ ('GRAPHICS_DEPTH')
     jw = ((3*iw+3)/4)*4                           ! each row starts on 4_byte address
   

   ! do ver = 0,id-1 do hor = 0,iw-1 ! get colour from direct addressing jj = ptr_RGB_Address + hor3 + verjw rgb_i(1) = core1(jj) ; if (rgb_i(1) < 0) rgb_i(1) = rgb_i(1)+256 ! blue rgb_i(2) = core1(jj+1) ; if (rgb_i(2) < 0) rgb_i(2) = rgb_i(2)+256 ! green rgb_i(3) = core1(jj+2) ; if (rgb_i(3) < 0) rgb_i(3) = rgb_i(3)+256 ! red rgb_all = rgb_i(3) + 256*(rgb_i(2) + 256*rgb_i(1)) …

(is there an intrinsic “byte (core1(jj))” which is an unsigned integer 0:255 ?) It may be that an alternative to user_surface is to use the DIB interface. DIB has the advantage of easier addressing of the graphics object, with character*1 PARRAY(3,mx,my), but an apparent problem with mx > 2048. Can anyone comment on the relative disadvantage of DIB vs , user_surface ?

John

Excellent thought, John - as long as you bear in mind the x-direction 2048 pixels limitation. If there's a way to get around that, it would be superb!

Meanwhile, I'm now working along the SVG route. Being vector-oriented rather than pixels, and also providing the scaleability, it has some distinbct advantages for mapping - I am working on geological and mine design applications. SVG does also offer a number of area-fill options, so usable for shaded maps too, not just line drawings. Small disadvantage for web appliocations is that it doesn't have the same web browser support as JPEG and GIF - it can be displayed in web pages, but through <object> rather than <img>.

I've also found that generating SVG is much faster than JPG or GIF, at least for the trivial test examples I've been running. File sizes tend to be quite small as well. Although the XML format is verbose, there's no need to store anything for blank areas, so for relatvely sparse graphics it's ideal.

Paul or Eddie,

Further to my previous post, could I ask:

1. Does the '%gr[user_surface]' allow the direct addressing pointer to change when select_graphics_object@ selects a virtual window ?
2. Would you expect that a DIB interface (with the selected graphics object) could perform at a similar speed to direct addressing, especially in comparison to the draw_point@ and Draw_Line_Between@ update approach.

It appears that there is a 2048 X limit with the DIB interface. Are you able to identify any possible limit in this area.

If user_surface does not support addressing the virtual screen, DIB may be a more flexible alternative. And, if DIB is significantly slower, I may need to use both.

I would appreciate any advice you may be able to provide.

John

I have managed to find a 2048 limit (in two places) and the limit proves to be avoidable. So this problem has now been fixed for the next release of salflibc.dll.

Regarding John's questions 1 and 2, currently user_surface has its own unique direct addressing pointer which cannot be changed (the whole thing is rather complex so I cannot be 100% sure that I am providing the correct answer to the question that you ask).

draw_point@ and draw_line_between@ provide interfaces into the API SetPixel and MoveTo and LineTo but I don't know how these functions perform in comparison with direct addressing.

Paul,

Thank you very much for identifying this limit. It will make DIB more flexible.

I have recently been reviewing the way I manage my graphics information using Clearwin+ and am finding I don’t fully understand what the limitations are for some methods. Some functionality I am mixing includes: • I have my own hidden line painting window (X,Y,Z,C), which I “dump” to the selected graphics window. This has to be managed when including text. • I have introduced screen window resizing, which I understand requires new memory allocation for the resized window. • I use both the screen window and other virtual windows via create_graphics_region@ and select_graphics_object@ . • I am now scanning the selected window to check the colour tablet being used for .gif dumps.

My %gr call has expanded to: i = winio@ ('%`^gr[grey, user_resize, rgb_colours, full_mouse_input, user_surface]&', & 1024, 768, & ! screen dimension when not maximised ptr_RGB_Address, & ! screen address for rgb surface ( not sure of the order ? ) w_handle, & ! supplied window handle defined in crtstart mouse_back_func) ! ^ call back function for mouse and resize

It appears to me that “user_surface” points to a bgr storage format, while DIB points to a rgb_format. For user_surface, each row is stored in an integer4 vector in blue green red order, while DIB uses a simpler integer1 (3,h,v) format in rgb order. Have I got this right? If I have, what storage format do create_graphics_regions use?

Some things I do not understand, related to this are: As there are a lot of legacy colour formats, is the screen window always stored in memory, or does this require rgb_colours or user_surface ? Does “ptr_RGB_Address”, which is a memory byte address, point to the screen information or the select_graphics_object ? Do legacy colour formats influence answers to these questions, making the memory management more complex?

Would it be possible to have a routine like: get_select_graphics_object_address@ (Byte_Address, WIDTH, HEIGHT, NBBP, ERCODE ) where “NBBP” (the number of bits per pixel) could be expanded to indicate the memory storage format, if required. Depending on the answers to questions above, this may be a useful addition. It may create a faster alternative to RECOVER_DIB_BLOCK@, allowing direct addressing of the selected graphics object.

The help file on “Direct manipulation of the graphics surface” also refers to use of window_update@ and GdiFlush(). Would the use of these calls be necessary in a Windows XP or 7 environment? My suggested routine may conflict with these calls.

I would appreciate what advice you are able to provide.

John