(old)Puppy Linux Discussion Forum

Posted: **Wed 16 Sep 2009, 03:30**

I compiled the latest mtPaint as a single compile (for >100kb or ~20% size reduction) the executable is now only 400kb

If someone wants to update/modernize the icons I will recompile it (see icons1.tar.gz)

FYI to get it to compile this small I had to do this in directory src:

Code: Select all

 gcc  -pipe -combine -Os -fno-pic -fno-PIC -ffunction-sections -fdata-sections \
 -momit-leaf-frame-pointer -fomit-frame-pointer -fmerge-all-constants \
 -mpreferred-stack-boundary=2  -march=i386 -mtune=i386 \
 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 \
 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 \
 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 \
 -I/usr/X11R7/include -I/usr/include/libpng12 \
 -DHAVE_MKDTEMP -DU_GIF -DU_JPEG -DU_TIFF -DU_FREETYPE -DU_FPICK_GTKFILESEL -DU_CPICK_GTK \
 -I/usr/include/freetype2 -DVERSION="\"mtPaint 3.31 Puppy Linux Edition"\" \
 main.c mainwindow.c inifile.c png.c memory.c canvas.c otherwindow.c mygtk.c \
 viewer.c polygon.c layer.c info.c wu.c prefs.c ani.c mtlib.c toolbar.c channels.c \
 csel.c shifter.c spawn.c font.c fpick.c icons.c cpick.c -o mtpaint \
 -Wl,-O,-Os,--gc-sections,-s,--no-keep-memory,--as-needed \
 /usr/lib/libgif.so /usr/lib/libjpeg.so /usr/lib/libtiff.so /usr/lib/libpng.so \
 /usr/lib/libgtk-x11-2.0.so /usr/lib/libgdk-x11-2.0.so /usr/lib/libatk-1.0.so \
 /usr/lib/libgio-2.0.so /usr/lib/libpangoft2-1.0.so /usr/lib/libgdk_pixbuf-2.0.so \
 /usr/lib/libpangocairo-1.0.so /usr/lib/libcairo.so /usr/lib/libpango-1.0.so \
 /usr/lib/libfreetype.so /lib/libz.so /usr/X11R7/lib/libfontconfig.so \
 /usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so /usr/lib/libglib-2.0.so -s
strip --strip-all --remove-section=.comment --remove-section=.note mtpaint

Posted: **Wed 16 Sep 2009, 07:44**

technosaurus wrote:FYI to get it to compile this small I had to do this in directory src:

A great example how failing to read docs leads one to heroically "solving" the wrong problem.

Code: Select all

./configure release gtkfilesel gtkcolsel nojp2

- results in a 429 Kb binary, when stripped the same way as yours - with full performance optimizations. While the one you produced is 400 Kb - optimized for size. Paying a 50% performance hit for 29 Kb of diskspace pre-compression - quite a tradeoff indeed.

BTW, none in the mixed bag of extra compiler options you've added have any positive effect on binary size - except "-Wl,--gc-sections" which saved whopping 120 bytes.

-= With best regards, Dmitry Groshev, maintainer of mtPaint =-

Posted: **Wed 16 Sep 2009, 10:47**

Well I re-themed my compile with tango/gnome icons which were bigger in overall size 22x22 instead of 20x20 but fix mostly on the 20x20 layer, still more colours etc and well it grew a bit, but I would rather have it look newer and toss like 45kb's out the door

Anyway can we could get a png version instead of xpm, the icon sizes would be a lot smaller plus when changing from tango png to xpm formats the transparencies get too dark and ruined. Thanks for your great product

ttuuxxx

Posted: **Wed 16 Sep 2009, 12:05**

ttuuxxx wrote:Well I re-themed my compile with tango/gnome icons which were bigger in overall size 22x22 instead of 20x20 but fix mostly on the 20x20 layer, still more colours etc and well it grew a bit, but I would rather have it look newer and toss like 45kb's out the door

Yes, definitely looks nice with these icons. But myself, I still prefer the original set - I like sharp outlines more than alpha blending.

Anyway can we could get a png version instead of xpm, the icon sizes would be a lot smaller plus when changing from tango png to xpm formats the transparencies get too dark and ruined.

To compile PNG icons into the binary, I'll need to write something to convert them into C source code - directly converting them to object files is architecture dependent:

Code: Select all

objcopy -I binary -O elf32-i386 -B i386 $< $@

But won't it be better to simply make mtPaint themeable? I can add "Default theme" entry to "Preferences->Paths", accepting a gtkrc file like the one here: /usr/share/gimp/2.0/themes/Default/imagerc . Then, everyone could easily switch to whatever iconset one prefers. The cost in terms of code size will be slight.
And naturally, this will support PNG icons out of the box.

Posted: **Wed 16 Sep 2009, 13:37**

wow that would be excellent if you could do that, then the icons would look 10X times better quality. They would have the same quality as gimp, because they are the same tango ones used by gimp, They lost a lot of quality when converting the original png to xpm, below is the same icons used in gimp. Plus it would make others who are used to gimp to know there way around mtpaint, now if we could just have a layers and colour wheel selection stationary on the right hand side,

ttuuxxx

Posted: **Wed 16 Sep 2009, 14:09**

wjaguar wrote:While the one you produced is 400 Kb - optimized for size. Paying a 50% performance hit for 29 Kb of diskspace pre-compression - quite a tradeoff indeed.

What is the 50% performance hit based on? Is that real world experience with your program or just a rule of thumb? I did some basic usage tests with -O2, -Os and -O3 and at least on my main 1.8ghz machine there was no noticable difference. I may pull out my DECtop (geode gx2) and run tests on it to verify, but I may wait for the theming - sounds great.

The reason I build it that way instead of using the make files is to test the effects of different optimizations (for myown educational purposes) -combine only works on .c files and not .o files and that tends to improve both performance and size (it works even better in later versions of gcc)

@ttuuxxx looks pretty good and it may actually save some size if there is theming since we could just use some symlinks then.

Posted: **Wed 16 Sep 2009, 15:02**

ttuuxxx wrote:wow that would be excellent if you could do that, then the icons would look 10X times better quality.

Technically, this is easy to do (now that I know how); the largest problem for me is actually assembling a set of icon files to test it on.

So it would be appreciated if you sent me the icons you used for your mtPaint build (PNGs, not XPMs) - my time saved on searching for the wherever the original files are on the Web, could then be put to better use actually implementing theming support.

now if we could just have a layers and colour wheel selection stationary on the right hand side

Actually, layers are there already, in current dev version:
http://mtpaint.sourceforge.net/temp/mtp ... 16.tar.bz2
Now, if layers window or settings toolbar aren't open as separate window, they are instead placed into the dock pane: "View->Show Dock"

As for colour selector (which one, BTW - A&B, or palette editor?), it is technically possible to put it in dock as well - but there is already no space remaining in the first pane, with settings and layers in there. So it'll have to go onto another page of the dock, and therefore could be shown only while settings-and-layers page is hidden.
Also, there is a separate question of undoing changes; now it is obvious - change to palette is pushed onto undo stack when user presses OK - but when to do so if colour editor is non-modal? (One more-or-less sensible possibility is - "when colour editor loses input focus".)

BTW, dynamic preview for all colour editors is already implemented in dev branch as well - the "Preview" button is now a toggle.

Posted: **Wed 16 Sep 2009, 15:23**

technosaurus wrote:What is the 50% performance hit based on? Is that real world experience with your program or just a rule of thumb?

This is Gaussian blur working 1.5 times slower on the machine I'm writing this on. The filter I normally use as a performance measure.

I did some basic usage tests with -O2, -Os and -O3 and at least on my main 1.8ghz machine there was no noticable difference.

Given that mtPaint is designed to handle "basic usage" even on a 486, the slowdown should have been an order of magnitude greater to be noticeable that way. Which is why I use a processing-heavy filter for testing performance.

The reason I build it that way instead of using the make files is to test the effects of different optimizations (for myown educational purposes)

This is what I said about ignoring the docs.

I've already tested available gcc options extensively, some time ago; picked those few optimizations which improve performance without disproportionately increasing the binary size, and made ' ./configure release ' enable them, and also disable GTK's debug code.

-combine only works on .c files and not .o files and that tends to improve both performance and size (it works even better in later versions of gcc)

On gcc 3.4.6, no effect at all; will try on gcc 4.2.3 later today and see what happens.

EDIT: And what happened was: on gcc 4.2.3, "-combine" saved 140 bytes.

Posted: **Wed 16 Sep 2009, 15:42**

wjaguar wrote:
ttuuxxx wrote:wow that would be excellent if you could do that, then the icons would look 10X times better quality.
Technically, this is easy to do (now that I know how); the largest problem for me is actually assembling a set of icon files to test it on.
.

Ok I'll do it, I'm in the middle of making a gtk2 theme so I'll be about 1hr or so

ttuuxxx

Posted: **Wed 16 Sep 2009, 16:48**

Ok here's the icons, There a lot of extras for you to choose from

ttuuxxx

Posted: **Wed 16 Sep 2009, 23:06**

ttuuxxx wrote:Ok here's the icons, There a lot of extras for you to choose from

OK, here is themeable mtPaint, and you can do the choosing yourself.

http://mtpaint.sourceforge.net/temp/mtp ... 17.tar.bz2

Now for each builtin XPM icon "src/icons1/xpm_whatever.xpm" there is matching stock ID "mtpaint_whatever", and if you define an icon for that ID in 'imagerc' (or whatever you decide to call the theme file), it will override the builtin one.
Naturally, this supports PNG icons and full alpha transparency - both are GTK2's builtin features, I only needed to make use of them.

Posted: **Wed 16 Sep 2009, 23:52**

Awesome, thanks so much for all your work on mtPaint. It continues to be a very integral part of Puppy.

Posted: **Thu 17 Sep 2009, 07:18**

Dear wjaguar,

Thanks very much for the new version of mtpaint and the new theming capability. Could you possibly provide a sample mtpaintrc, or a bit of it, so that I can see the proper syntax. I have tried

Code: Select all

mtpaint_save="/root/media-floppy.png"

as a test but got no results. Without the quotes I got an error message. I am certain that the solution is simple.

With kind regards,
vovchik

Posted: **Thu 17 Sep 2009, 08:13**

vovchik wrote:Could you possibly provide a sample mtpaintrc, or a bit of it, so that I can see the proper syntax.

Here it is:

Code: Select all

gtk-icon-sizes="gtk-small-toolbar=22,22"
style "mtPaint" {
        stock["mtpaint_brcosa"] = {
                { "color-brightness-contrast.png", *, *, * }
        }
# Other icon definitions go here
}
widget_class "*" style "mtPaint"

The complete documentation on allowed syntax and what it means, is here: http://library.gnome.org/devel/gtk/stab ... Files.html, under the "Styles" heading.

Posted: **Thu 17 Sep 2009, 08:38**

Dear wjaguar,

Thanks very much. I didn't realize that you were using standard gtk2 rc syntax. I will now try that out and report on my progress.

With kind regards,
vovchik

Posted: **Thu 17 Sep 2009, 14:24**

Dear wjaguar,

Everything works as you said it would. My mtpaintrc file looks like this:

Code: Select all

# choose a location (directory) for your mtpaint theme (icon dir)

pixmap_path "/root/.mtpaint-theme/"

# icon definitions go here 

style "mtPaint" { stock["mtpaint_brcosa"] = { { "mtpaint_brcosa.png",*, *, * } } }
style "mtPaint" { stock["mtpaint_case"] = { { "mtpaint_case.png",*, *, * } } }
style "mtPaint" { stock["mtpaint_centre"] = { { "mtpaint_centre.png",*, *, * } } }
style "mtPaint" { stock["mtpaint_cline"] = { { "mtpaint_cline.png",*, *, * } } }
style "mtPaint" { stock["mtpaint_clone"] = { { "mtpaint_clone.png",*, *, * } } }
style "mtPaint" { stock["mtpaint_close"] = { { "mtpaint_close.png",*, *, * } } }
style "mtPaint" { stock["mtpaint_config"] = { { "mtpaint_config.png",*, *, * } } }

.... (and so on)

widget_class "*" style "mtPaint"

many thanks and kind regards,
vovchik

Posted: **Thu 17 Sep 2009, 16:45**

Hi vovchik when your finished could you please post a skinned version

with the mtpaintrc and icons. That would save everybody a lot of time figuring it, I'm more foccused on 2.20 and don't have time figure this out from scratch.
Thanks
ttuuxxx

Posted: **Thu 17 Sep 2009, 17:48**

Dear ttuuxxx,

Here is my mtpaintrc and my .mtpaint-theme (hidden) dir full of png icons. I bashed this set together quickly, using some of your icons and some others that are supposed to match my OSX GTK/KDE/QT/IceWM themes. All this should be unpacked in /root.

With kind regards,
vovchik

PS. More work could be done, as evidenced by my screen shot

Posted: **Thu 17 Sep 2009, 18:00**

vovchik wrote:Dear ttuuxxx,

Here is my mtpaintrc and my .mtpaint-theme (hidden) dir full of png icons. I bashed this set together quickly, using some of your icons and some others that are supposed to match my OSX GTK/KDE/QT/IceWM themes. All this should be unpacked in /root.

With kind regards,
vovchik

PS. More work could be done, as evidenced by my screen shot

vovchik it saves me a lot of time so thank you

ttuuxxx

Posted: **Thu 17 Sep 2009, 18:40**

vovchik wrote:Here is my mtpaintrc and my .mtpaint-theme (hidden) dir full of png icons.

Good that you included setting "gtk-icon-sizes" in your mtpaintrc. But for best results, the size which mtPaint uses should be set to precisely the unscaled size of the icons. Like this:

Code: Select all

gtk-icon-sizes="gtk-small-toolbar=22,22"

Because, see, GTK's image scaling code is completely braindead, and its results are of a very bad quality.

And if an icon is originally larger than needed, it is better to rescale it with mtPaint, than leave the job to GTK+.
First, "Scale canvas" - with default "Blackman-Harris" method, gamma correction enabled, and "Sharper image reduction" in settings toggled on.
Then, "Unsharp mask" for improving the contrast - a good working recipe is one pass with radius 1 and amount 0.40, and then another with radius 30 and amount 0.10. (This is what Wikipedia engine does when serving reduced-size images, since 2007.)

BTW, image scaling was the reason why I got involved with mtPaint: no existing program was able to do it properly, so I had to implement it myself.

(old)Puppy Linux Discussion Forum

mtpaint 3.34+svn

mtpaint 3.34+svn

Crippling other people's software is nothing to be proud of

Re: Crippling other people's software is nothing to be proud of

Re: Crippling other people's software is nothing to be proud