Erasing text leaves shadow/stop graphics swapping to desktop

[SteveA]

I have been using the excellent openvg lib by ajstarks and have come across a few problems, which I hope can be resolved.

1. For example - I create a full screen graphics window in red and set the font to 24 point white (both alpha = 1.0) and draw a text string at a set place on the screen. To erase that particular text I change its colour to the same as the screen (red) and redraw it at exactly the same place.

The string is, in effect, erased, but you can still see a faint outline of the font shapes in white.

You will notice a related problem if you draw the string in white on a fresh red screen then redraw the same string still in white at the same place. The characters should stay the same, but on the second drawing they thicken.

It is a though a 2nd and subsequent drawing of the same text (same parameters) at the same place on the screen is being drawn slightly different to the 1st draw.

I would like to fix the issue so that I can erase sections of text leaving other prompts unaffected.

2. I boot the Raspberry Pi into the desktop and from a separate PC, linked by ssh, I run my graphics program and everything (apart from the above) is fine. If I also use the keyboard on the Raspberry Pi it is also fine (I scan both keyboards and treat them the same within the program). However, if I do not touch either keyboard for some minutes and then touch the Raspberry Pi's keyboard, the graphics display turns off and the desktop reappears.

If I constantly use the keyboard there is no problem - it is only when it is left for a short time.

I wondered if it was the Raspberry Pi going into sleep mode and so I have disabled it (supposedly), yet the problem persist.

Does anyone have any pointers or is there a way to keep the 'pinging' something from within my program to stop this timeout happening and returning to the desktop.

Thanks for looking

[jojopi]

The first effect is due to anti-aliasing. Pixels around the edges of the characters, that are partially inside and partially outside the true outline, are half-shaded to give a less jagged perimeter. Half-shading a pixel again in the same colour further changes the shade, and half-shading back to the previous colour does not fully undo the effect.

In general, information has been lost when you have drawn over something, even transparently, so you should not expect to be able to undraw an object without repainting the whole scene.

I do not understand what you mean about scanning both keyboards—that is not especially easy to do. If the GUI is also responding to the USB keyboard invisibly in the background, then that is not a very good way to operate.

I cannot reproduce your issue, though. It does not matter if Xorg blanks and unblanks the framebuffer, because the OpenVG overlay is in front.

[SteveA]

Thanks for explaining the cause of the first problem being due to anti-aliasing. I was hoping to just erase the text rather than erasing a rectangular block, which is what I original did and does work. If you know of a way to overcome this, I would be pleased to hear about it.

You are right that it is not particularly easy to scan both keyboards (and I also scan a barcode reader). The keyboard you start the application from (which could be the one connected via ssh from another PC) becomes the stdin keyboard and so the keyboard attached to the Raspberry Pi USB is then ignored. . It took me a long time to work it out how to detect a key event then decode it and so I can now read/scan from both keyboards one after the other.

For info: the reason I scan (ie c = mykybscan() and if c>0 there is a char) rather than use getchar() to detect if a character is there is so that I do not get blocked as would happen when using getchar() whilst waiting for the enter key to be pressed.

I need to do a master loop, looking at sensors, reading ADC, updating graphics, then scan the keyboards/barcode for a char without stopping at all, and when a char is detected action it, eg if it is up arrow, alter sampling rate or something, etc, with getting stuck/blocked. I have to do the same when I get a string; I scan within the master loop adding each keypress as they occur to a strgbuf[]. It is to try and use a Raspberry Pi, which has excellent graphics capabilities (when I learn them all) in the same way that I use my embedded controllers.

The problem I get is as explained; when I start the application from one keyboard and keep using the other every minute or so, all is fine. But if I do not use the other for say 10 minutes the moment I press a key on the the Raspberry Pi kyb the screen flips back to the desktop and I loose my graphics window (loose the focus?). I am looking at how to keep the graphics window displayed until my program does an actual finish()

Thanks

[Paeryn]

The problem I get is as explained; when I start the application from one keyboard and keep using the other every minute or so, all is fine. But if I do not use the other for say minutes the moment I press a key the Raspberry Pi flips back to the desktop and I loose my graphics window (loose the focus?). I am looking at how to keep the graphics window displayed until my program does an actual Finish()

Is your program exiting, crashing or being killed? It sounds like it.

The OpenVG graphics "window" isn't a window that X knows about or has any control over, if it has gone and you have the desktop back then either (a) your program closed it itself, (b) your program finished/died forcing the window to close or (c) some other program managed to re-arrange the display layers to move your window to be behind the desktop.

The only program that I know that resets the display (and gets rid of all open graphics layers) is tvservice, if you change the screen mode with that then all layers are removed and would need to be re-added, but I can't see X using it.

[SteveA]

Thanks Paeryn - the actual program is still running as seen on the connected PC via ssh, because the diagnostic data (adc, loop counts, etc) values are still being read and displayed in the connected ssh PC's terminal and so the program has not finished, even though the graphics layer has gone. It is 'just' the graphics layer on the Raspberry Pi which disappears and flips to the desktop.

It is as though the RPI has gone in effect to sleep and so when you press the RPI's attached keyboard (not the ssh keyboard), it wakes the RPI up from its sleep and flips the display to the desktop (as was originally there when my program first started).

Is there a way to reinstate the graphics layer without redrawing the lot again? Or a way to keep internally keep it alive. I do not know about the tvservice and so will need to look into that.

I am away in a short while and so will be away from my setup for a few weeks - I will probably be a bit quiet until I return.

Thanks again for suggestions

[jojopi]

Do you get the same problem if you run one of the example programs like hellovg or shapedemo, wait for the GUI to go to screensaver, then press a key? I do not—the framebuffer blanks and unblanks but the OpenVG layer always stays visible on top.

If the problem affects other programs, then the "sleep mode" you are referring to is something different than I am seeing. Otherwise it is something specific to your code; perhaps the way you are intercepting the USB keyboard.

[Paeryn]

I was about to reply the same as jojopi, for me when X times out the screen it just blanks the framebuffer, other layers stay open fine.

Could you provide a sample of your code that reproduces this problem?

[SteveA]

I am on my way at moment and so will try the suggestions when I get back. Thanks

[ajstarks]

See: https://github.com/ajstarks/openvg/blob ... ip/clip.go

for an example of text updating

[SteveA]

I have not been around for awhile, hence my delay in responding. Since my last post I have gone through my code from top to bottom and whilst I could find plenty of rubbish I needed to tidy up and streamline, I could not see a definitive issue so I then decided to update the Raspberry Pi and all its libs afresh (as my original setup was a RPIB and the one I now use which had the problem is a RPI2). I updated everything including the firmware by doing:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade
sudo apt-get autoremove
sudo apt-get clean
sudo rpi-update
sudo reboot

Q: are there any more update items you know of or recommend to be done?

I then recompiled everything again. Now I do not experience the graphics window dropping out and displaying the original desktop after 10 mins of inactivety then inputting from the attached USB keyboard or USB barcode reader. If this stays OK for the next few days I will be pleased.

I now need to find out how to save areas on the graphics window to a jpeg file so I can do screen snapshots.

Thanks for looking
Steve

[SteveA]

Thanks ajstarks for the example of text updating. Is there also an example in 'c' somewhere, as I do not have the Go package.

Is there a link to learn the syntax of Go programming?

Thanks

[Paeryn]

Thanks ajstarks for the example of text updating. Is there also an example in 'c' somewhere, as I do not have the Go package.

https://github.com/ajstarks/openvg/blob ... ent/clip.c

Is there a link to learn the syntax of Go programming?

https://golang.org

[SteveA]

Thanks to you all who answered and gave valuable advice and pointeres. The graphics layer now does not flip back to the desktop when the attached USB keyboard is touched after over 10mins of inactivety. I believe it is now fixed and I am sure that the firmware update I did was the cure for this. My RPI2 was one of the first batch with very old firmware and since this update it has been running fine.

Thanks for the link to the Go documentation - it looks interesting and is all totally new to me. I see that the Go documentation mentions ClipRect and ClipEnd, yet the C documentation I have does not (hence the reason I did not know about the clip functions, which are proving very useful). Is there a link to the updated C documentation which includes these (and more) functions? If I have missed it, apologies.

In ClipRect I see that the co-ords are VGint whereas all of the other co-ords for positioning text, drawing rects/boxes/lines/circles, etc, are VGfloats. When I clip to a panel's co-ords, which use VGfloats I cast the values to VGints to stop the compiler warnings. Is there any reason that ClipRect do not use VGfloats the same as the rest. I ask, not as a problem, but simply out of interest.

Thanks
Steve

[Paeryn]

ClipRects are ints because that is what OpenVG expects, they are screen-space coordinates and not transformed unlike the other coordinates used in drawing.

[ajstarks]

I have updated the README to include the clipping functions.