Aranym screen driver does not honour offscreen bitmap handle

[mfro0]

all drivers (tested with firebee.sys and bitmap.sys) appear to support offscreen bitmaps opened with v_opnbm() just fine.
GDP output is redirected to that bitmap and can be copied from there to the screen.

While the aranym.sys driver also opens a bitmap using v_opnbm() without error, it does not draw to the bitmap representing the passed bitmap handle with any output function, but what appears to be the physical screen workstation instead (output overwriting the XaAES menu bar items).

[th-otto]

I'm currently looking into this, and i'm facing several problems:

• the driver routines currently always call into aranym. But aranym only manages a screen surface, and does not know about in-memory bitmaps. That's why everything appears on screen (typically in the upper left corner).
• it is not even easy to check whether a vwk is the screen or not. At

  fvdi/fvdi/engine/workstn.c

  Line 279 in c05474e

  new_wk->screen.mfdb.address = mfdb->address;

  both the address of the mfdb and the mfdb.screen.address are set to the same value. So i think that even code like

  fvdi/fvdi/drivers/16_bit/16b_scr.c

  Line 36 in c05474e

  if (!dst || !dst->address || (dst->address == wk->screen.mfdb.address)) {

  will think it is writing to the screen. Same currently happens for aranym:

  fvdi/fvdi/drivers/aranym/dispatch.c

  Line 50 in c05474e

  else if (mfdb->address == vwk->real_address->screen.mfdb.address)

  has the effect of always passing "NULL" as the destination address.
• v_opnbm() should be able to deal with bitmaps in screen format, and with monochrome bitmaps. For bitmaps in screen format the driver functions typically can be used, but not for monochrome unless the screen itself is monochrome.

@mfro: can you test whether drivers (except aranym.sys) really work when the created bitmap has other dimensions than the screen?

[th-otto]

There are also some really hard to find places where the fallback functions pass a NULL MFDB address, eg.

fvdi/fvdi/engine/blit.s

Line 65 in c05474e

clr.l -(a7)

fvdi/fvdi/engine/blit.s

Line 406 in c05474e

clr.l -(a7) ; No MFDB => draw on screen

[th-otto]

Made some progress:

The screenshot is from a new zView module which uses v_opnbm() to replay GEM Metafiles. There are certainly other programs that can be used for testing, eg. Pupul:

I've pushed the current changes to a "offscreen" branch. There may be more changes needed, especially for monochrome bitmaps (i preferrably need some test program for this).

Most of the changes were done in aranym, though. Theoretically, some of work could have also been done in the aranym driver, but aranym needs to know anyways whether to draw to the screen or to atari memory (not only to avoid drawing the bitmap on the screen, but also because the host screen is backed up by a SDL surface, with different byte order). And even if the format is the same, the dimensions of an offscreen bitmap may be different than the ones of the screen. Therefor some changes may still be required also for other drivers.

I'm still thinking about a way to make the detection bullet-prof. Currently, wk->screen.type is mostly used for this (will be 0 for offscreen, and non-zero for screen). But that only works when really using v_opnbm(), i'm quite sure that there are programs that simulate v_opnbm() by allocating the bitmap on their own, and setting Logbase() to that address while drawing into it. That will be a bit difficult to detect, because in this case, always a normal VDI handle for the screen will be used. Don't know whether it makes sense to support such programs, since they probably will also mess with the Line-A variables.

Using the wk->screen.mfdb.address also is not very reliable i think. There are just too many cases:

• It can be 0, as is currently the case for aranym.sys.
• It can be non-zero, as is the case for most other drivers.
• It will always be the same as the src/dest in blit operations on handles returned from v_opnbm(), but can also be the same for screen blits.
• Most functions do not even pass a separate MFDB, so i can only use the MFDB of the workstation handle.

Changes to aranym are pushed (you obviously need to compile it yourself, if you want to test this). I'm quite sure there needs more to be done.