Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
58 user(s) are online (39 user(s) are browsing Forums)

Members: 0
Guests: 58

more...

Headlines

 
  Register To Post  

(1) 2 »
Vector based icon plugin - progress update
Just can't stay away
Just can't stay away


See User information
I now have a more or less working svg converter using libsvgtiny and simple viewer for the new vector icon format using cairo.

The vector format is a binary IFF-like format so it's much easier to parse than svg and also more compact. I'm also considering adding support for compression through z.library and maybe bz2.library (I will have to test first if it's worth it though).

The main problem I'm looking at at the moment though is that I can't really use cairo in the iconmodule and even if I could I don't really want to because of it's size and that it comes with so many large dependencies that are totally useless to me: libpng, libz, libfreetype, libfontconfig, libexpat, libpthread, ...

After looking at some alternatives I'm currently looking at libart which although it seems like much more work to use than cairo but at least seems to fit all of my requirements:
1. It's not very large
2. Has no external dependencies
3. Doesn't use global or static variables (could be easily made into a .library even)
4. Doesn't use GPL license (it uses LGPL)
5. Only supports drawing into pixel buffers (I don't need or want anything else)
6. Completely written in C (no C++ code in sight)

The biggest issue with it that I can see ATM is that it uses RGBA for it's 32-bit format rather than ARGB which is what the AmigaOS icon.library expects but this should be easily fixable one way or another (either by changing libart or by adding an extra conversion pass after rendering).

BTW the libart port that's on OS4Depot (by Andrea Palmate) is a bit out of date so I'm going to upload my newer port (version 2.3.20) along with the source code and my handwritten Makefile as the source code seems to be a bit hard to find on the net (it's supposed to be part of the gnome project but it seems they may have gotten rid of it as I couldn't find it there).

Go to top
Re: Vector based icon plugin - progress update
Amigans Defender
Amigans Defender


See User information
Quote:

salass00 wrote:
The vector format is a binary IFF-like format


Any reason to create a new one, rather than using DR2D?

Quote:
After looking at some alternatives I'm currently looking at libart which although it seems like much more work to use than cairo but at least seems to fit all of my requirements:
1. It's not very large
2. Has no external dependencies
3. Doesn't use global or static variables (could be easily made into a .library even)
4. Doesn't use GPL license (it uses LGPL)
5. Only supports drawing into pixel buffers (I don't need or want anything else)
6. Completely written in C (no C++ code in sight)


Or you could use graphics.library

Go to top
Re: Vector based icon plugin - progress update
Just can't stay away
Just can't stay away


See User information
Quote:

Any reason to create a new one, rather than using DR2D?


I need a custom format anyway to have different normal and selected icon imagery and to store icon metadata like snapshot data and tooltypes f.e.

The vector data in my format is just a raw data stream for my vector renderer so it's very easy to generate with libsvgtiny and to parse later.

Quote:

Or you could use graphics.library


Last I checked graphics.library didn't support such features as sub-pixel positioning, anti-aliasing and drawing lines of different widths.

While I could solve the lack of anti-alias by simply drawing at a higher res and then averaging over the pixels this would also make the lines thinner.

Also with graphics.library I have to draw into a bitmap while icon.library expects a FreeAlloc() allocated ARGB32 buffer so I would have to draw into a temp bitmap first and then copy the data from there.

Go to top
Re: Vector based icon plugin - progress update
Just can't stay away
Just can't stay away


See User information
I have done a preliminary version of the vector icon viewer using libart instead of cairo but there seems to be some problems still with some shapes not being drawn as can be seen from this comparison image:
Resized Image

The window on the left is the viewer using cairo and the one on the right is the libart one.

The stripped executable sizes for comparison:
71104 Dec 1 09:47 test/showicon_cairo
75556 Dec 1 10:02 test/showicon_libart

The cairo one uses shared objects while the libart one is statically linked.

Go to top
Re: Vector based icon plugin - progress update
Supreme Council
Supreme Council


See User information
@salass00

Nice! I wish there were more active devs like you on openamiga :)

Vacca foeda. Sum, ergo edo

Mr Bobo Cornwater
Go to top
Re: Vector based icon plugin - progress update
Amigans Defender
Amigans Defender


See User information
@salass00

It's only the background missing. I had a similar problem, in that 0x00000000 is transparent, rather than black. The issue is because something doesn't support the alpha component, which defaults to 0x00. If you initialise all your colours to 0xffffffff this will probably fix it without needing to do anything else.

Go to top
Re: Vector based icon plugin - progress update
Just can't stay away
Just can't stay away


See User information
@Chris

It's not as simple as that. ATM I only draw into a 24-bit RGB buffer with libart and then blit this to the window using BltBitMapTags() with BLITA_SrcType set to BLITT_RGB24 without any alpha channel.

Changing the colour of the background box doesn't help make it visible and it's not the only thing that is missing (the white border on the lower left cloud is also missing).

Go to top
Re: Vector based icon plugin - progress update
Just can't stay away
Just can't stay away


See User information
Looks like libart has too many problems for me to be able to use it so I'm currently looking at building a static version of libcairo with the features I don't want disabled.

Unfortunately I already ran into a problem trying to configure libpixman with -mbaserel:
$ ./configure --prefix=/SDK/local/newlib --host=ppc-amigaos --disable-vmx CFLAGS=-mbaserel --enable-static=yes --enable-shared=no --enable-libpng=no --enable-gtk=no
...
configure: error: in `/home/salass00/Development/Projects/pixman-0.28.0':
configure: error: C compiler cannot create executables
See `config.log' for more details

This is what is in the config.log file:
configure:3505: ppc-amigaos-gcc -mbaserel conftest.c >&5
/usr/local/amiga/lib/gcc/ppc-amigaos/4.2.4/../../../../ppc-amigaos/bin/ld: cannot find -lc
collect2: ld returned 1 exit status

If I remove the -mbaserel it configures just fine but I need it because pixman uses a global variable for cache so this isn't an option.

Edit:
I found the reason why it can't find -lc. When I copied over my SDK install to Ubuntu it didn't copy over the soft links unfortunately so I've had to fix them by hand afterwards. Obviously I missed these ones since I haven't needed them until now:
Quote:

8.RAM Disk:> list SDK:newlib/lib/baserel/
Directory "SDK:newlib/lib/baserel" on Sunday 02-Dec-12
crtbegin.o 2096 ----rw-d 02-Jun-08 16:45:04
crtend.o Link ----rw-d Future 03:04:02
> /crtend.o
libamiga.a Link ----rw-d Future 03:04:09
> ///clib2/lib/baserel/libamiga.a
libauto.a Link ----rw-d Future 03:04:02
> /libauto.a
libc.a Link ----rw-d Future 03:04:02
> /libc.a
libdebug.a Link ----rw-d Future 03:04:09
> ///clib2/lib/baserel/libdebug.a
libm.a Link ----rw-d Future 03:04:02
> /libm.a
libraauto.a Link ----rw-d Future 03:04:02
> /libraauto.a
libsocket.a Link ----rw-d Future 03:04:02
> /libsocket.a
libunix.a Link ----rw-d Future 03:04:02
> /libunix.a
1 file - 2K bytes - 9 unresolved softlinks - 15 blocks used
8.RAM Disk:>


Edited by salass00 on 2012/12/2 9:06:58
Go to top
Re: Vector based icon plugin - progress update
Amigans Defender
Amigans Defender


See User information
you should try to use AGG

i'm really tired...
Go to top
Re: Vector based icon plugin - progress update
Just can't stay away
Just can't stay away


See User information
@afxgroup

AGG is C++ so it would mean a lot more trouble trying to use it from shared library and I'm not too good with C++ either way. Also the latest versions are under GPL license which I would rather avoid since it would mean that the iconmodule couldn't be included with the OS.

Apart from that I have already compiled minimal libcairo and libpixman libraries using -mbaserel for use in the iconmodule. The cairo configure script seemed to be pretty angry at me for disabling all that extra stuff but now I have libcairo and libpixman without any external dependencies.

Go to top
Re: Vector based icon plugin - progress update
Just can't stay away
Just can't stay away


See User information
@Chris

Is any work being done to add gradient support to libsvgtiny in the near future?

Go to top
Re: Vector based icon plugin - progress update
Not too shy to talk
Not too shy to talk


See User information
Hello

>The vector format is a binary IFF-like format
Please document this format when it will be ready
Also perhaps define icone positions as x y z so may be used in the future in a 3D workbench

Alain Thellier

Go to top
Re: Vector based icon plugin - progress update
Amigans Defender
Amigans Defender


See User information
Quote:

salass00 wrote:
@Chris

Is any work being done to add gradient support to libsvgtiny in the near future?


None that I know of. You can ask Daniel Silverstone but I suspect the answer will be "patch welcome".

Go to top
Re: Vector based icon plugin - progress update
Just can't stay away
Just can't stay away


See User information
@thellier

Quote:

>The vector format is a binary IFF-like format
Please document this format when it will be ready


I will.

Go to top
Re: Vector based icon plugin - progress update
Just can't stay away
Just can't stay away


See User information
@Chris

Quote:

None that I know of. You can ask Daniel Silverstone but I suspect the answer will be "patch welcome".


I guess I will look into it when I have the rest of the iconmodule working then...

Go to top
Re: Vector based icon plugin - progress update
Just can't stay away
Just can't stay away


See User information
This project rocks!

Go to top
Re: Vector based icon plugin - progress update
Just can't stay away
Just can't stay away


See User information
Some progress:

Resized Image

Go to top
Re: Vector based icon plugin - progress update
Home away from home
Home away from home


See User information
Absolutely awesome, thanks for sharing salass00

People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
Go to top
Re: Vector based icon plugin - progress update
Home away from home
Home away from home


See User information
@Salass00 Quote:
Also the latest versions are under GPL license which I would rather avoid since it would mean that the iconmodule couldn't be included with the OS.

I don't think the GPL prevents bundling (aka "mere aggregation") of GPLed files with non-GPLed files:
http://www.gnu.org/licenses/gpl-faq.html#MereAggregation

Author of the PortablE programming language.
Go to top
Re: Vector based icon plugin - progress update
Just can't stay away
Just can't stay away


See User information
Quote:

I don't think the GPL prevents bundling (aka "mere aggregation") of GPLed files with non-GPLed files:
http://www.gnu.org/licenses/gpl-faq.html#MereAggregation


Not bundling as such but bundling a GPL plugin with a non-GPL program (workbench/icon.library) would be breaking the GPL license, at least according to the xvidcore developers:
http://www.xvid.org/FAQ.42.0.html

Quote:

Q: We don’t link to Xvid at all, just call through the VfW interface upon run-time – can we distribute with our proprietary software?

A: No. It doesn’t matter in which way you link to Xvid or what you count as linking and what not. The GPL doesn’t focus on the term ‘linking’ at all but rather requires combined/derived works to be published as a whole under the terms of the GPL. Basically any two (or more) pieces make up a combined work when they are distributed for use in combination. Hence, if your program calls upon Xvid functionality at run-time it would make up a derived work - no matter how you technically implement the calls to Xvid. If you don’t want to publish your program under the GPL then refrain from distributing it in combination with Xvid.


Go to top

  Register To Post
(1) 2 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project