Vector based icon plugin - progress update

	Bottom Previous Topic Next Topic
Register To Post

(1) 2 »

salass00

Posted on: 2012/11/30 10:14 #1

Just can't stay away

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).

Chris

Re: Vector based icon plugin - progress update

Posted on: 2012/11/30 10:35 #2

Amigans Defender

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

salass00

Re: Vector based icon plugin - progress update

Posted on: 2012/11/30 10:57 #3

Just can't stay away

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.

salass00

Re: Vector based icon plugin - progress update

Posted on: 2012/12/1 8:12 #4

Just can't stay away

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.

orgin

Re: Vector based icon plugin - progress update

Posted on: 2012/12/1 8:25 #5

Supreme Council

@salass00

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

Vacca foeda. Sum, ergo edo

Mr Bobo Cornwater

Chris

Re: Vector based icon plugin - progress update

Posted on: 2012/12/1 12:03 #6

Amigans Defender

@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.

salass00

Re: Vector based icon plugin - progress update

Posted on: 2012/12/1 13:42 #7

Just can't stay away

@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).

salass00

Re: Vector based icon plugin - progress update

Posted on: 2012/12/2 8:40 #8

Just can't stay away

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

afxgroup

Re: Vector based icon plugin - progress update

Posted on: 2012/12/2 10:28 #9

Amigans Defender

you should try to use AGG

i'm really tired...

salass00

Re: Vector based icon plugin - progress update

Posted on: 2012/12/2 11:14 #10

Just can't stay away

@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.

salass00

Re: Vector based icon plugin - progress update

Posted on: 2012/12/3 7:41 #11

Just can't stay away

@Chris

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

thellier

Re: Vector based icon plugin - progress update

Posted on: 2012/12/3 9:08 #12

Not too shy to talk

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

Chris

Re: Vector based icon plugin - progress update

Posted on: 2012/12/3 10:59 #13

Amigans Defender

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".

salass00

Re: Vector based icon plugin - progress update

Posted on: 2012/12/4 8:16 #14

Just can't stay away

@thellier

Quote:

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

I will.

salass00

Re: Vector based icon plugin - progress update

Posted on: 2012/12/4 8:25 #15

Just can't stay away

@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...

spotUP

Re: Vector based icon plugin - progress update

Posted on: 2012/12/4 16:32 #16

Just can't stay away

This project rocks!

salass00

Re: Vector based icon plugin - progress update

Posted on: 2012/12/5 8:16 #17

Just can't stay away

Some progress:

Resized Image

Raziel

Re: Vector based icon plugin - progress update

Posted on: 2012/12/5 8:59 #18

Home away from home

Absolutely awesome, thanks for sharing salass00

--

game box/art scans
scummvm infrequent builds

ChrisH

Re: Vector based icon plugin - progress update

Posted on: 2012/12/5 10:09 #19

Home away from home

@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.

salass00

Re: Vector based icon plugin - progress update

Posted on: 2012/12/5 12:00 #20

Just can't stay away

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.

Register To Post	(1) 2 »
	Top Previous Topic Next Topic

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