Hardware pointers and cursors.

Anything QL Software or Programming Related.
User avatar
Dave
SandySuperQDave
Posts: 2417
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Hardware pointers and cursors.

Postby Dave » Fri Jun 21, 2019 5:21 pm

One of the huge inefficiencies of WIMP systems on the QL is the manually drawn and redrawn pointers (and cursors generally).

I've been playing with a system that enabled hardware pointers. For those not in the know, this is an interesting shift of responsibility from OS to hardware.

Currently, the OS takes a snapshot of the video memory, then splices a pointer into it, then when the pointer moves or changes it copies the original back, makes a new snapshot and splices the new pointer or position into that. If the pointer crosses a word boundary, it has to move twice the memory. With a hardware pointer, none of this happens, but on boot all the pointers are copied into the frame-buffer, configured as foreground, background and mask colours. Then during use, the pointer is just spliced into the output stream. It uses a fractional amount of the OS and CPU's resources.

What might be involved in altering the OS to not write in manual pointers and cursors? What kind of improvements might this bring, besides responsiveness of the pointer?

I'm using a pair of bitmap graphic ICs that bring support for up to 16 hardware pointers, which can have two foreground colours, a mask colour, and just need to be selected so (eg: a single word instruction can say "place cursor N at X,Y" and it will be non-destructively spliced there without disrupting the underlying data in video memory.

The device does not support native QL bit format (though this is fixable) but it does natively support Aurora bit format in any software definable resolution. It also has some integrated BLIT (block move) functions that would allow the OS to request a window area be saved/copied to another area, or back.


Nasta
Gold Card
Posts: 337
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: Hardware pointers and cursors.

Postby Nasta » Tue Jun 25, 2019 12:19 am

To make a long story short, the gain in responsiveness will be disappointingly small if at all observable. And it will come at considerable complication to drivers, because under PE the cursor can be more than a 2-bit deep bitmap with the given hardware limitations. The OS updates the cursor under vertical synch interrupt at which point it also stops any update to the screen by jobs in order not to corrupt the screen or the cursor itself. It's a fairly small amount of data that is seldom updated.


stephen_usher
Trump Card
Posts: 160
Joined: Tue Mar 11, 2014 8:00 pm

Re: Hardware pointers and cursors.

Postby stephen_usher » Tue Jun 25, 2019 7:04 pm

Basically a hardware cursor is effectively a single hardware sprite. It's drawn on a graphics plane above the "background" normal graphics plane and composited on top by the graphics chip for the output.

Not only does it have the benefit that the underlying graphics software doesn't have to do any damage repair but it also means that the shape can be redefined on the fly by pointing the graphics chip at a different pixmap image to render.

I can imagine that any QL GUI system was never written with such a system in mind and hence probably doesn't separate the pointer move from the damage redraw code, which would be a problem. Speedwise it should be reasonably large as graphics memory would never be touched as long as the cursor was merely moved as the instruction to do this to the chip would merely be "display cursor at these co-ordinates" and it would do it internally and there would be no need to redraw the damage left behind.

However, it would no doubt need quite a re-write of the base code, not just a driver I'd imagine.


User avatar
Dave
SandySuperQDave
Posts: 2417
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Hardware pointers and cursors.

Postby Dave » Wed Jun 26, 2019 12:18 am

Nasta wrote:To make a long story short, the gain in responsiveness will be disappointingly small if at all observable. And it will come at considerable complication to drivers, because under PE the cursor can be more than a 2-bit deep bitmap with the given hardware limitations. The OS updates the cursor under vertical synch interrupt at which point it also stops any update to the screen by jobs in order not to corrupt the screen or the cursor itself. It's a fairly small amount of data that is seldom updated.


I don't know what's complicated about copying the sprite into the pointer framebuffer, then whenever the pointer code is called because the mouse moved, setting the pointer number, X and Y registers, then replacing the rest of the driver with NOPs?

stephen_usher wrote:Not only does it have the benefit that the underlying graphics software doesn't have to do any damage repair but it also means that the shape can be redefined on the fly by pointing the graphics chip at a different pixmap image to render.

And this chipset supports 16 pointers preloaded into the framebuffer, so switching between them is just a single register write.

stephen_usher wrote:I can imagine that any QL GUI system was never written with such a system in mind and hence probably doesn't separate the pointer move from the damage redraw code, which would be a problem. Speedwise it should be reasonably large as graphics memory would never be touched as long as the cursor was merely moved as the instruction to do this to the chip would merely be "display cursor at these co-ordinates" and it would do it internally and there would be no need to redraw the damage left behind.

However, it would no doubt need quite a re-write of the base code, not just a driver I'd imagine.


Isn't that the challenge? :D

I wasn't saying a general responsiveness improvement, but a pointer responsiveness improvement. Instead of taking thousands of CPU cycles to move the pointer a single pixel, this could be done with three register writes.

The responsiveness improvements would come from copying and pasting content behind windows using the blitter function, which is seven register writes. You're then free to continue using your system while the block is copied in the background - with the proviso that you wait for it to be copied before overwriting anything in that video area.


Nasta
Gold Card
Posts: 337
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: Hardware pointers and cursors.

Postby Nasta » Wed Jun 26, 2019 2:24 am

Dave wrote:
Nasta wrote:To make a long story short, the gain in responsiveness will be disappointingly small if at all observable. And it will come at considerable complication to drivers, because under PE the cursor can be more than a 2-bit deep bitmap with the given hardware limitations. The OS updates the cursor under vertical synch interrupt at which point it also stops any update to the screen by jobs in order not to corrupt the screen or the cursor itself. It's a fairly small amount of data that is seldom updated.


I don't know what's complicated about copying the sprite into the pointer framebuffer, then whenever the pointer code is called because the mouse moved, setting the pointer number, X and Y registers, then replacing the rest of the driver with NOPs?


Let me repeat myself: because under PE the cursor can be more than a 2-bit deep bitmap
So, no problem if you can load an 8-bit or 16-bit deep cursor image into 2-bit deep storage.., which also implies one out of 4 combinations are for transparency and yet another for inversion, so it's not really 4 colors.
Now, it's not as if could not be done, except that you have to enforce your own standard of cursor handling to anything pointer driven, which implies using the hardware as it is, which in turn requires modifications to all PE programs. Is this requirement worth saving time to update a piece of screen that's usually less than 16x16 pixels on the screen?
If one wants to use it as a regular alphanumeric cursor, it's at most 16x16 pixels again.


User avatar
Dave
SandySuperQDave
Posts: 2417
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Hardware pointers and cursors.

Postby Dave » Wed Jun 26, 2019 2:33 am

I've never used the PE for longer than it takes to disable it. In that brief time I have observed that it displays a no entry symbol of red on white, and a pointer of two colours, and sometimes a question mark of two colours. I have never been exposed to how they are internally formatted.

Even the simplest BASIC program can create and use pointers without even touching the PE, so it could be as simple as just trapping the calls to write the pointer. It probably isn't, because nothing QL is ever as relaxed as it could be. The entire platform is a concretion of fixes to patches to work arounds of a "feature" that didn't work properly in FB ;)


Derek_Stewart
QL Wafer Drive
Posts: 1472
Joined: Mon Dec 20, 2010 11:40 am
Location: Runcorn, Cheshire, UK

Re: Hardware pointers and cursors.

Postby Derek_Stewart » Wed Jun 26, 2019 8:47 am

Hi,

SMSQ/E can change the cursor to a 10x6 sprite, with the CURSPRLOAD command, does this change anything?

Would the system see the used defined sprite cursor as something different?

Quite an important question, lets say, that the P.E. is disabled and there is a new flashy game with software sprites, can this be handled OK.

What is "FB"?


Regards,

Derek
User avatar
Ralf R.
Over Heated PSU
Posts: 147
Joined: Fri Jun 15, 2018 8:58 pm

Re: Hardware pointers and cursors.

Postby Ralf R. » Wed Jun 26, 2019 9:01 am

Derek_Stewart wrote:What is "FB"?

FlashBack?


Nasta
Gold Card
Posts: 337
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: Hardware pointers and cursors.

Postby Nasta » Wed Jun 26, 2019 9:33 am

Dave wrote:I've never used the PE for longer than it takes to disable it. In that brief time I have observed that it displays a no entry symbol of red on white, and a pointer of two colours, and sometimes a question mark of two colours. I have never been exposed to how they are internally formatted.

Even the simplest BASIC program can create and use pointers without even touching the PE, so it could be as simple as just trapping the calls to write the pointer. It probably isn't, because nothing QL is ever as relaxed as it could be. The entire platform is a concretion of fixes to patches to work arounds of a "feature" that didn't work properly in FB ;)


Trapping what calls? Only the PE implements them as a (rather involved) extension to the regular con/scr drivers.
Re pointer color - depends on what the display mode is and of course what the program is. The default pointers for the general PE UI are all mode 4. But then, there is QTOP...
Of course, USING a pointer is far more than just displaying it. And regarding PE - it's what we have. It's actually not nearly as convoluted as window systems on many other more popular computers - none of the ones that are truly capable are simple (and that's an understatement). The PE never got a really proper integrated tool chain. Basic is also a problem because the PE uses data structures that are not easy to manage in basic, and it's also event driven which is again a problem in basic.


User avatar
mk79
Gold Card
Posts: 391
Joined: Sun Feb 02, 2014 10:54 am

Re: Hardware pointers and cursors.

Postby mk79 » Wed Jun 26, 2019 11:08 am

Nasta wrote:Let me repeat myself: because under PE the cursor can be more than a 2-bit deep bitmap
Even more than that, the PE can alpha-blend the mouse cursor unto the background. I know because I've written that feature. And as mentioned even the text cursor can be a sprite, meaning it can alpha blend with the text below it.

Marcel



Who is online

Users browsing this forum: No registered users and 4 guests