User avatar
ajstarks
Posts: 129
Joined: Fri Jun 22, 2012 2:14 am

OpenVG library updates

Fri Jan 08, 2016 1:45 am

I have merged in changes from Paeryn. These include:

Ability to change window sizes, opacity, and positions
TextHeight and TextDepth functions
AreaClear and WindowClear functions
Outlined shapes
Names colors

Thanks for the feedback and code.

tito-t
Posts: 298
Joined: Thu Jan 07, 2016 5:14 pm

Re: OpenVG library updates

Fri Jan 08, 2016 9:01 am

hello,
I am very new to Raspberry Pi and I happened to stumble on that openvg library topic - that's really great!
By the way, I have a question about the colors: is there a list of the colors somewhere which can be used now?

I discovered that there is already another topic about this
viewtopic.php?f=38&t=130650&hilit=openv ... 25#p878158
would it be better to continue asking questions over there?
- Tim

User avatar
Paeryn
Posts: 1755
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: OpenVG library updates

Fri Jan 08, 2016 12:26 pm

Thanks for including the updates. I've had a quick look and prefer your prefix for the colour defines. I'll sync my fork over the weekend.
She who travels light — forgot something.

tito-t
Posts: 298
Joined: Thu Jan 07, 2016 5:14 pm

Re: OpenVG library updates

Fri Jan 08, 2016 2:54 pm

hello,
did you find colour defines anywhere? I could not find them! Thank you in advance!
- Tim

User avatar
Paeryn
Posts: 1755
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: OpenVG library updates

Fri Jan 08, 2016 4:15 pm

They are at the bottom of the new shapes.h. All colour names are prefixed with color_ so red is color_red
She who travels light — forgot something.

tito-t
Posts: 298
Joined: Thu Jan 07, 2016 5:14 pm

Re: OpenVG library updates

Fri Jan 08, 2016 4:39 pm

now I see it in ajstarks' library, thank you!
will it also be included into your fork in the same way, Paeryn?
- Tim

User avatar
Paeryn
Posts: 1755
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: OpenVG library updates

Fri Jan 08, 2016 4:51 pm

Yes, when I wrote it I prefixed the colour names with SH_ but ajstarks' naming is better (and whereever possible I'll keep compatibility with his). I may get chance to re-sync my fork tonight but it might not be until Sunday.
She who travels light — forgot something.

tito-t
Posts: 298
Joined: Thu Jan 07, 2016 5:14 pm

Re: OpenVG library updates

Fri Jan 08, 2016 11:08 pm

ok, I missed that point. Will then both forks be identical or will there still be differences?
- Tim

User avatar
Paeryn
Posts: 1755
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: OpenVG library updates

Sat Jan 09, 2016 12:24 am

I've only had chance to have a quick glance at what ajstarks merged in but I think it's pretty much what I had. My fork was a bit behind, I don't know what all the changes were that he'd done but I think it was mainly Go related. I'll know better when I get around to syncing my fork on Sunday (got home late tonight and I don't feel like going through it yet).
Basically if ajstarks included everything of mine then when I sync up then the two will be pretty much identical (I'll be changing the SH_ prefix to colour names in mine to match ajstarks' color_ prefix and bringing in whatever he's done since I last synced).

The only difference I do know of is that I changed the Makefile slightly to allow easy cross compiling on my setup (it makes it easier for me as I edit the code on my PC and rely on being able to compile from within the editor) and ajstarks didn't merge that in, but it shouldn't make any difference for compiling on the RPi.

My next change (the only other thing at the moment I'd like to play with) will be to add in direct loading of truetype fonts whereas at the moment you need to convert them first with the font2openvg program, and to switch rendering of fonts to use openvg's native glyph functions rather than just drawing paths as is the case currently (I don't know if the RPi's openvg implementation supports auto-hinting of fonts, but if it does then this method can use it). It also allows for easy use of bitmapped fonts for when speed is a priority over the ability to smoothly scale.
She who travels light — forgot something.

tito-t
Posts: 298
Joined: Thu Jan 07, 2016 5:14 pm

Re: OpenVG library updates

Sat Jan 09, 2016 9:03 am

at Ajstarks and Paeryn:
Thank you both for providing the libraries with all the features!
at Paeryn:
I meanwhile already saw in another openvg thread (started by devnull) that you have announced to simplify the font installation.
That is really amazing because it's still really complicated for the moment.
Other questions which I had also could be resolved meanwhile having read through other threads by the way.
Thank you all for your efforts!
- Tim

User avatar
ajstarks
Posts: 129
Joined: Fri Jun 22, 2012 2:14 am

Re: OpenVG library updates

Sat Jan 09, 2016 1:58 pm

I have opened two issues on github related to the library updates:

#41 - to track the recent changes from Paeryn https://github.com/ajstarks/openvg/issues/41
#42 - to track changes in font handling. https://github.com/ajstarks/openvg/issues/42

User avatar
Paeryn
Posts: 1755
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: OpenVG library updates

Sun Jan 10, 2016 6:16 pm

I think I've merged my fork with ajstarks now (I'm new to github so I might have done something wrong). If anybody previously using my fork updates, the colour defines have now changed prefix from SH_ to color_.

I've kept my Makefile changes in my version because I need them for ease of cross-compiling but I think that is the only difference at this point. My version checks for an environment variable RPISDK and if it's set then it uses that as the base directory for the /opt/vc/ stuff e.g. if RPISDK=/home/user/rpi then /opt/vc/include becomes /home/user/rpi/opt/vc/include and it changes the compiler from gcc to arm-linux-gnueabihf-gcc
She who travels light — forgot something.

User avatar
Paeryn
Posts: 1755
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: OpenVG library updates

Tue Jan 12, 2016 12:15 am

New branch V1.3 on my fork github.com/paeryn/openvg/tree/V1.3

I've made a few minor changes to how font information is passed, previously the whole Fontinfo struct was passed which, since it's nearly 2KB, is quite a bit for each call to the Text functions. This is a precursor to my main font handling changes.

Now Fontinfo is a pointer to a struct Fontinfo_T (the old Fontinfo is now Fontinfo_T). It means that for the majority of the time no changes are required to your source code (unless you manually loaded fonts).

Due to the change in function signatures this library is binary-incompatible with previous versions, therefore I've upped the version number for linking to 2. This allows keeping the old version for programs that were linked against it (although the soname wasn't explicitly set in the previous version so programs linked against it might try loading the new version anyway and cause a seg fault {edit - I've updated the fonts branch to set the soname of the library}).

Changes:
Fontinfo is now a pointer to a struct rather than a struct.

loadfont() now allocates the memory required to hold a Fontinfo_T and returns the pointer to it (so it still returns a Fontinfo, it's just returning a pointer now rather than copying 2KB of data). Since I was changing it, it now takes two more arguments at the end - the font's descender and ascender heights (previously I avoided changing the signature and required you to manually set them if you wanted to use the TextHeight and TextDepth functions). New call is

Code: Select all

#include "DejaVuSans.inc"
Fontinfo DejaFont = loadfont(DejaVuSans_glyphPoints, 
        DejaVuSans_glyphPointIndices, 
        DejaVuSans_glyphInstructions,                
        DejaVuSans_glyphInstructionIndices, 
        DejaVuSans_glyphInstructionCounts, 
        DejaVuSans_glyphAdvances,
        DejaVuSans_characterMap, 
        DejaVuSans_glyphCount,
        DejaVuSans_descender_height,
        DejaVuSans_ascender_height);
unloadfont() now takes Fontinfo as it's sole argument, it unloads the glyphs and frees the memory the loadfont() allocated.

Code: Select all

unloadfont(DejaFont);
The Text() functions should all work as before.

Unfortunately I messed up my git commits. Branch V1.2 shouldn't have been updated, somehow it got most of the changes that were meant for V1.3 and I can't see how to roll back the change. I think the fonts branch is pretty much what V1.2 was anyway.
She who travels light — forgot something.

tito-t
Posts: 298
Joined: Thu Jan 07, 2016 5:14 pm

Re: OpenVG library updates

Tue Jan 12, 2016 9:24 am

hello,
is this now the final font handling change which you have announced before? Or will there be one more change which makes it even more easy just to include either font type as a *.ttf file in some subdirectory?
My next change (the only other thing at the moment I'd like to play with) will be to add in direct loading of truetype fonts whereas at the moment you need to convert them first with the font2openvg program, and to switch rendering of fonts to use openvg's native glyph functions rather than just drawing paths as is the case currently (I don't know if the RPi's openvg implementation supports auto-hinting of fonts, but if it does then this method can use it). It also allows for easy use of bitmapped fonts for when speed is a priority over the ability to smoothly scale.
- Tim

User avatar
Paeryn
Posts: 1755
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: OpenVG library updates

Tue Jan 12, 2016 9:41 am

No, that is still under way. When I started writing the new stuff I realised that in the original whenever Fontinfo was passed to/from a function it was being passed as a struct, and that struct is nearly 2KB long, so each function call was wasting time copying over 2000 bytes of data needlessly. This change is to convert Fontinfo into a pointer to struct and as such only takes 4 bytes to pass it.
She who travels light — forgot something.

tito-t
Posts: 298
Joined: Thu Jan 07, 2016 5:14 pm

Re: OpenVG library updates

Tue Jan 12, 2016 9:59 am

that's fine, thank you very much for your clarification Paeryn! :)
- Tim

davenull
Posts: 1162
Joined: Thu Oct 22, 2015 7:22 am
Location: a small planet close to Betelgeuze

Re: OpenVG library updates

Sat Feb 06, 2016 6:28 pm

hey'all,
is there a update meanwhile for including original TTF fonts without compiling them before ?
#define S sqrt(t+2*i*i)<2
#define F(a,b) for(a=0;a<b;++a)
float x,y,r,i,s,j,t,n;int main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PointOut(x,y);}}}for(;;);}

User avatar
Paeryn
Posts: 1755
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: OpenVG library updates

Sat Feb 06, 2016 6:58 pm

davenull wrote:hey'all,
is there a update meanwhile for including original TTF fonts without compiling them before ?
Sort of. I've had that part working for a while, but it has an unfortunate side-effect of sometimes causing the gpu to stall for 5-10 seconds (sometimes quite a bit longer) randomly - even if you never draw any text. I'm in the middle of trying to figure out what is causing it.
She who travels light — forgot something.

davenull
Posts: 1162
Joined: Thu Oct 22, 2015 7:22 am
Location: a small planet close to Betelgeuze

Re: OpenVG library updates

Sat Feb 06, 2016 7:28 pm

good luck! gladly looking forward to! :) :) :)
#define S sqrt(t+2*i*i)<2
#define F(a,b) for(a=0;a<b;++a)
float x,y,r,i,s,j,t,n;int main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PointOut(x,y);}}}for(;;);}

User avatar
Paeryn
Posts: 1755
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: OpenVG library updates

Mon Feb 08, 2016 3:58 am

An interim update for anybody that wants to test the new system (dynamic font loading, shape and paint objects). Due to several differences in how fonts are handled, this version is not binary compatible with the old one. I updated the version number for the library, but I don't think ajstark's original sets it properly so any code compiled to use the old library may try loading the new version if it's installed at the same time. If this is a problem then don't install this version, but rather link directly to it in the way the demos do in client/Makefile - I may change the library name to something like shapes-exp instead to avoid this in future.

https://github.com/paeryn/openvg/tree/newfonts

Documentation will come in a few days, along with new demos - Best information at the moment is found reading the source code and the demos client/chars.c and client/ptest.c
Things might change in the future at any time, this is experimental work-in-progress based on how I see potential improvements. ajstarks is ultimately in-charge of his library, this is just my testbed, I'll try to keep compatibility a priority but if I think things need to be different (hello Fontinfo)... I'm keeping ajstarks up-to-date with what I'm doing and I'll be working with him to integrate any changes he wants. Oh, and the Go integration will probably be messed up - I won't attempt to update that whilst the C code is in flux.

In addition to the libraries that ajstark's original requires, this version requires libfontconfig1 to be installed (not sure if libfontconfig1 is installed by default, but you'll need to install libfontconfig1-dev anyway to compile the library)

Code: Select all

sudo apt-get install libfontconfig1-dev
The new font system is up and running so you can load fonts easily at runtime. At the moment it requires setting the ctype locale property properly within your program if you want to print anything other than basic ascii strings (like UTF-8 or accented characters), if you don't then it will ignore any string that doesn't conform. I'm probably going to go back to defaulting to UTF-8 since this is a pain. To do this put something like this at the start

Code: Select all

#include <locale.h>  // Needed for setlocale()

int main()
{
    setlocale(LC_CTYPE, "");
    ...
}
New fonts can be loaded either by giving their filename, or if the font is installed, by using it's family name (the system will then pick the nearest font it can find if what you asked for isn't available).

Code: Select all

Fontinfo myFont = LoadTTFFile("/path/to/myfont.ttf"); // Loads a font by filename
Fontinfo myFont = LoadTTF("DejaVuSans"); // Loads a font by family name
unloadfont(myFont); // Frees the font
Fonts don't have to be truetype, it handles postscript-type1 too (although it doesn't seem to load the kerning data for those even though I ask it to) - and any other outline font that freetype handles - though I don't have any to check.
Kerning (adjusting inter-character spacing for combinations like WA) will happen too for fonts loaded like this as long as the font provides it (so the default 3 fonts won't), this can be switched off on a font-by-font basis.

The new system causes programs that do a lot of drawing to have stalls (I've seen anywhere between 5-30 seconds). From what I've seen this could happen previously anyway - but the new system causes it to happen sooner. I think (from several days trying to follow what the system is doing) is that because the library originally created and destroyed paths constantly, the gpu is keeping old data around (it needs to if it hasn't gotten around to drawing before you destroy the object) then the stall happens when it finally tries to clean up. I've added a bunch of functions that rather than drawing the shapes, just create an object and return a handle to it. You create all the shapes you need outside the main drawing routines (where possible), and in the drawing loop you call the function to draw them. This is how OpenVG is meant to work anyway.

I've not gotten around to documenting, but the file client/chars.c shows drawing the new fonts, and client/ptest.c shows using the new paths (it's a modified version of client/particles.c).
Quick example usage

Code: Select all

#include "shapes.h"
VGPath myCircle;
VGPath MyRect;
VGPaint myRed;
VGPaint myWhite;

void allocData()
{
    myCircle = CirclePath(0, 0, 20); // a circle, radius 20 units, origin is it's centre at (0,0)
    myRect = RectPath(0, 0, 15, 30); // A rectangle, origin is bottom-left corner at (0,0) 15 units wide by 30 high
    myWhite = Paint(255, 255, 255, 1.0f); // White paint
    myRed = Paint(color_red, 1.0f); // Red paint using the color_ define
}

void drawScene()
{
    StrokeWidth(1); // 1 pixel wide outlines
    WindowClear(); // Clear the screen
    StrokePaint(myRed); // Set the outline to the red we defined
    FillPaint(myWhite); // Set the fill to the white we defined
    DrawPath(myRect); // Draw the rectangle we defined with the origin at 0,0
    DrawPathAt(100, 100, myCircle); // Draw the circle with it's origin translated to (100,100)
    End();
}

void freeData()
{
    DeletePaint(myRed);
    DeletePaint(myWhite);
    DeletePath(myRect);
    DeletePath(myCircle);
}

int main()
{
    int w, h, i;
    init(&w, &h);
    allocData();
    for (i = 0; i < 60; i++) {
         drawScene();
    }
    freeData();
    finish();
    return 0;
}
Compiling needs to include freetype and fontconfig since the library needs them now.

Code: Select all

gcc -Wall -I/opt/vc/include -I/opt/vc/include/interface/vmcs_host/linux -I/opt/vc/include/interface/vcos/pthreads -o demo demo.c -L/opt/vc/lib -lshapes -lEGL -lGLESv2 -lbcm_host -pthread -ljpeg -lfreetype -lfontconfig
She who travels light — forgot something.

Return to “OpenVG”

Who is online

Users browsing this forum: No registered users and 1 guest