Pure OpenVG app

Anything and everything about programming graphics with Ultibo
Halted
Posts: 3
Joined: Mon Jun 04, 2018 5:36 am

Pure OpenVG app

Postby Halted » Wed Jun 20, 2018 12:50 pm

Hi,

I have an app which must essentialy display informations (clock, chronograph, notifications ...)
I have been able to use OpenVG but at startup there is the empty green console showing (but any code related to console was removed).
Is there a way to start directly in OpenVG mode ?

I read that only main thread should display with OpenVG. What is the best way to synchronize between threads ?

Is there a "timer" emulation other than sleeping and finding out that a second has passed ?

Many thanks for your help.

JM
User avatar
Ultibo
Site Admin
Posts: 2040
Joined: Sat Dec 19, 2015 3:49 am
Location: Australia

Re: Pure OpenVG app

Postby Ultibo » Thu Jun 21, 2018 12:41 am

Hi,

Three good questions and each of them have a few different options, I'll outline your choices below.

As always if you are not clear which method would be best for your use then simply post a bit of a description of what you are wanting to achieve and we'll try to recommend one.

Halted wrote:I have an app which must essentialy display informations (clock, chronograph, notifications ...)
I have been able to use OpenVG but at startup there is the empty green console showing (but any code related to console was removed).
Is there a way to start directly in OpenVG mode ?

By default the framebuffer console device will attach itself to any framebuffer device it finds and create a console (the green background). If you don't want or need the console then you have three choices to disable this behavior.

1. Don't include the Console unit, although since the RaspberryPi/2/3 helper units which are designed to include all of the common units and drivers into a project include console by default you would need to create your own version of the same thing to use instead.

2. Set the global variable FRAMEBUFFER_CONSOLE_AUTOCREATE to False in the GlobalConfig unit and rebuild the RTL, you would need to remember to reapply this change whenever you download an updated RTL as well.

3. Use an InitUnit to override the FRAMEBUFFER_CONSOLE_AUTOCREATE setting during boot. We have demonstrated this in a couple of other posts but basically you create an empty unit outline (we normally call it InitUnit) and add it as the first unit in the uses clause of your program file (so it will be processed before all other units). The init unit contains just an initialization section and looks like this:

Code: Select all

unit InitUnit;

{$mode delphi} {Default to Delphi compatible syntax}
{$H+}          {Default to AnsiString}
{$inline on}   {Allow use of Inline procedures}

interface

uses GlobalConst,GlobalConfig;

implementation

initialization
 {Disable Console Autocreate}
 FRAMEBUFFER_CONSOLE_AUTOCREATE:=False;
 
end.

That will override the FRAMEBUFFER_CONSOLE_AUTOCREATE setting and prevent console devices from being created automatically. Note that you can override many other settings in the same unit as well.

Halted wrote:I read that only main thread should display with OpenVG. What is the best way to synchronize between threads ?

It isn't that only the main thread should display OpenVG, more that only the thread which performed the OpenVG initialization can write to the display. This is built in to the userland libraries for the Raspberry Pi and while it could be changed it is possibly heavily woven into the design.

The situation is very similar to the GUI elements of the FCL (or Delphi VCL) which should only be accessed from the main thread so the same sorts of solutions can be used.

The FPC RTL supports calling Synchronize() from any TThread object, this allows passing a method to the main thread to be executed. The TThread class also supports the Queue() method as well which is similar to Synchronize() but doesn't wait.

In order for this to work your main thread needs to call CheckSynchronize() regularly, so if you have a main program loop then it would include a call to CheckSynchronize() to process those messages from other threads.

The Ultibo API includes other options as well such as ThreadSendMessage() and ThreadReceiveMessage() (or ThreadReceiveMessageEx to control the timeout), these allow passing a structure similar to the TMessage record used in Windows messages and can be used to create an effective thread to thread communication mechanism. There are also more advanced structures as well that allow messages to be distributed to a pool of threads and so forth.

Halted wrote:Is there a "timer" emulation other than sleeping and finding out that a second has passed ?

The TFPTimer class from the FPC RTL works in Ultibo although it also relies on the Synchronize() method by default so again your main thread would need call CheckSynchronize() regularly.

There is also a TTimerEx class in the UltiboClasses unit which doesn't use Synchronize() and uses the built in functions from Ultibo instead.

Other options include the Timer and Worker functions from the Threads unit and the Timer devices from the Devices unit, each has their own reasons for existing and each has cases where it might be the better choice.

Hope that helps, let us know if you need more info on any of this.
Ultibo.org | Make something amazing
https://ultibo.org
Gavinmc42
Posts: 1399
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Pure OpenVG app

Postby Gavinmc42 » Thu Jun 21, 2018 1:34 am


Return to “Graphics”

Who is online

Users browsing this forum: No registered users and 1 guest