pUPnGO - 6Mb ISO - Basic Building Block Puplet

A home for all kinds of Puppy related projects
Message
Author
User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#741 Post by technosaurus »

Re: added functions.
If you are talking shared lib size, you can include uncommon functions in the .h instead of the .c, but the gotcha is you need to ifndef it in the .h so you can define something like -DBUILDLIB to exclude it, that way future builds will build a static object and hopefully ffunction/gc-sections will pull it from bulds that dont need it.

If youve ever looked in a config.h (and how it is generated) it may be clear using the HAVE_/NEED_ defs as examples ... I think jwm has a shell version.

This is actually an interesting approach to overall shared lib size reduction in general and could be extended to easily inlined small functions that consist of a single conditional + a return ... Since they arent included in the .so, it shrinks and since the inlined code is smaller than a funtion call + return for these really basic fxns.

Youd be surprised how often a giant series of ifelses, can be reduced to a ternary op
return ( A || B && C)? -1 : 0:
Where the A,B,C expression is the eqivalent of the ifelse.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#742 Post by technosaurus »

Re: added functions.
If you are talking shared lib size, you can include uncommon functions in the .h instead of the .c, but the gotcha is you need to ifndef it in the .h so you can define something like -DBUILDLIB to exclude it, that way future builds will build a static object and hopefully ffunction/gc-sections will pull it from bulds that dont need it.

If youve ever looked in a config.h (and how it is generated) it may be clear using the HAVE_/NEED_ defs as examples ... I think jwm has a shell version.

This is actually an interesting approach to overall shared lib size reduction in general and could be extended to easily inlined small functions that consist of a single conditional + a return ... Since they arent included in the .so, it shrinks and since the inlined code is smaller than a funtion call + return for these really basic fxns.

Youd be surprised how often a giant series of ifelses, can be reduced to a ternary op
return ( A || B && C)? -1 : 0:
Where the A,B,C expression is the eqivalent of the ifelse.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#743 Post by goingnuts »

Thanks! The permanent size increase is in static linked apps - I havent tested if the size of the dynamic linked also is permanently larger.

In the actual xlib case there seems to be 3-4 entries that triggers the added size: In GetColor.c, LookupCol.c and ParseCol.c we have a structure like below:

Code: Select all

Status
XLookupColor (
	register Display *dpy,
        Colormap cmap,
	_Xconst char *spec,
	XColor *def,
	XColor *scr)
{
	register int n;
	xLookupColorReply reply;
	register xLookupColorReq *req;
#ifdef USECMS
	XcmsCCC ccc;
	XcmsColor cmsColor_exact;
/* more code removed */
#endif
where the #ifdefs are mine. If included in the lib the size-increase is there even though the functionality is not used by the application - but the function "XLookupColor" is used so it drags the rest in...

It looks like an extension to XlookupColor as the content include this statement

Code: Select all

 /*
	 * Let's Attempt to use Xcms and i18n approach to Parse Color
	 */
User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#744 Post by technosaurus »

I wonder what is i18n about color lookup? if it is localized color names (never seen them)? can an lgettext -> C locale be a sufficient replacement? I am tempted to convert an rgb.txt as a switch case in C similar to my file mimetype code (it will add some size internally, but could speed things up and not require an rgb.txt)
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#745 Post by goingnuts »

I am not sure but rgb.txt might be case sensitive - at least the names can be done in many ways:

Code: Select all

248 248 255		ghost white
248 248 255		GhostWhite
245 245 245		white smoke
245 245 245		WhiteSmoke
At least icewm (or is it imlib) benefits from the added xcms functions - maybe mostly because the format #xxyyzz is widely used in icewm-themes - but I still cant see a way to conditionally use or exclude the xcms.

After playing with tinyX11 + MESA + freeglut doing fvs & tdfsb a wish for making small videos of screen-events popped up...
After testing recordmydesktop (which build static but refuses to run) I went through various versions of xvidcap. The newer versions seems quite gnome dependent but the older 1.0.XX version builds ok and run.
Last version is xvidcap-1.0.19 and a static build is attached.
For creating a video external programs are still needed. Mencoder or ffmpeg can be used (transcode as well). ppm2mpeg is a script which works well with xvidcap and I have included it in the attached pet.
For editing, tools from ImageMagick are called but they are HUGE when static linked.

A quote from the xvidcap README:
This program does not use a special hardware driver to access the
video card. It just asks the X server about rectangular areas. This
means you need a fast machine (>= 133 MHz) and a fast harddrive. Big
frames (e.g. 384x288 = 1/2 PAL) at a high FPS rate are only possible
with very very fast systems
:)
amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#746 Post by amigo »

Where did you find that version of xvidcap sources? I only find dead links to them.
goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#747 Post by goingnuts »

amigo: Sources are here
Needed below small patch to be able to compile:

Code: Select all

--- ./src/mngutil.c.01	2003-10-13 22:53:52.000000000 +0800
+++ ./src/mngutil.c	2013-09-02 17:01:15.000000000 +0800
@@ -30,13 +30,13 @@
 #include <png.h>
 #include "mngutil.h"
 
-extern void png_write_data (png_structp png_ptr,
+/*extern void png_write_data (png_structp png_ptr,
 				png_bytep data,png_size_t length);
 extern void png_save_uint_32 (png_bytep buf, png_uint_32 i);
 extern void png_save_uint_16 (png_bytep buf, png_uint_16 i);
 extern void png_write_chunk (png_structp png_ptr,
 				png_bytep chunk_name, png_bytep data, png_size_t length);
-
+*/
 png_byte mng_sig[8] = {138, 77, 78, 71, 13, 10, 26, 10};
 
 /*
User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#748 Post by technosaurus »

goingnuts wrote:I am not sure but rgb.txt might be case sensitive - at least the names can be done in many ways:
Yep, but when you strip the white space from and tolower the requested color, they are == (except for gray!=grey , but switch-case has fall through)... need to figure out which function(s) look at rgb.txt to figure out a good return format though
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#749 Post by amigo »

@GN -thanks for the patch.
goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#750 Post by goingnuts »

@technosaurus: Some scripts and application reads rgb.txt direct - if not present they might fail...

I am trying to get a working version of ImageMagick - I have static builds of 3.6, 4.2.9, 5.2.2 and 6.8.6-9 - increasing in size from 700Kb to 4400Kb for "display". But running "display" is unstable with all versions. Even normal build in P412 linked dynamic is not stable. Xvesa/Xorg various settings does not help.
Problem is that the command menu works maybe every second time. Described here as well. Anyone knows more about this and how to solve?
User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#751 Post by technosaurus »

goingnuts wrote:@technosaurus: Some scripts and application reads rgb.txt direct - if not present they might fail...
should be easy enough to patch those, but I may take a look in the xserver code to see what it uses to send the colors, I've been meaning to see how hard it would be to port xfbdev to xcb anyhow
I am trying to get a working version of ImageMagick - I have static builds of 3.6, 4.2.9, 5.2.2 and 6.8.6-9 - increasing in size from 700Kb to 4400Kb for "display". But running "display" is unstable with all versions.
unstable how? doesn't "display" just do the same thing as meh/feh with support for a few extra formats?
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#752 Post by goingnuts »

ImageMagick display can do image editing (annotations, oilpaint, sharpen etc) ...leftclick in the imagewindow and a menu pops up with all the possibilities. Unstable in the sense that the menu pops up but only "now-and-then" you can use it.

Further tests shows that icewm, xfce and fvwm do not give the problem so its likely to be a jwm-issue...

Attached quick implementation (from jwm commit da207c3) fix it but I don't like patching jwm for a problem only seen in ImageMagick...

Found hints to jwm here

Slight update: The quick patch does not solve everything - haven't expected that anyway. The jwm-762 solves everything concerning ImageMagic but adds unwanted stuff too: Apps writing to root background cant be seen anymore and the sticky windows are back in pager. Besides that is seems to run ok. Attached a static linked version of jwm-762.

I would have liked to patch ImageMagic instead but cant find my way in its code. So I will let it rest as is for now. Version 4.2.9 seems to do more than just the basic things needed to work with xvidcap-1.0.19 so made a multi call binary of all the tools (animate combine convert display identify import mogrify montage xtp) which ends up 1391Kb linked static and 517Kb upxed. Not small enough to post here but I have created a pet-package for download ImageMagick-4.2.9.pet here [591K].
Also attached patch used to facilitate the mcb-build.
Note: Build without tiff-support...
Attachments
ImageMagic.png
ImageMagic-4.2.9 running in exp-pupngo with jwm-762
(121.47 KiB) Downloaded 821 times
ImageMagick-4.2.9_mcb01.diff.gz
fake .gz
(5.65 KiB) Downloaded 297 times
jwm.gz
fake .gz - static linked jwm-762
(192.31 KiB) Downloaded 303 times
jwm_2.0.1_IM_try.diff.gz
(5.79 KiB) Downloaded 288 times
goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#753 Post by goingnuts »

Further blah on xvidcap...
Seems that Xt is used alone until version 1.0.19. After that gtk2 is introduced but Xt is kept until version 1.1.3 and removed from 1.1.4 and from there and on becomes more gnomish.
I did not succeed embedding ffmpeg in 1.0.19 but can do it with 1.1.3. Choose not to as it seems better to be able to choose which version of ffmpeg we want for other usage. A static linked version of xvidcap-1.1.3 with a slightly modified ppm2mpeg +a static linked ffmpeg-0.4.8 and its corresponding ffplay + ImageMagic-4.2.9 can be downloaded here - [xvidcap-1.1.3_plus_ffmpeg_0.4.8_plus_IM-4.2.9.pet/2Mb]
amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#754 Post by amigo »

I wasn't able to compile either 1.0.19 or 1.1.3 -even with your png patch. Are you probably using png12? I have png14 here after finding and patching several progs/libs which were written for png12.

I finaly got 1.0.19 compiling by deleting the mng_write_sig from xtomng.c. The program runs but i don't know yet if it works.

After a simple './configure' command, here's the errors when trying to build 1.1.3pl1:

Code: Select all

Making all in src
make[2]: Entering directory `/home/amigo/Downloads/xvidcap/xvidcap-1.1.3-p7/src'
if gcc -DHAVE_CONFIG_H -I. -I. -I..    -DVERSION=\"1.1.3\"     -g -O2 -MT xvidcap-mngutil.o -MD -MP -MF ".deps/xvidcap-mngutil.Tpo" \
          -c -o xvidcap-mngutil.o `test -f 'mngutil.c' || echo './'`mngutil.c; \
        then mv -f ".deps/xvidcap-mngutil.Tpo" ".deps/xvidcap-mngutil.Po"; \
        else rm -f ".deps/xvidcap-mngutil.Tpo"; exit 1; \
        fi
mngutil.c:36:13: error: conflicting types for 'png_save_uint_16'
/usr/include/png.h:2823:1: note: previous declaration of 'png_save_uint_16' was here
mngutil.c: In function 'mng_write_sig':
mngutil.c:49:2: warning: 'sig_bytes' is deprecated (declared at /usr/include/png.h:1255)
mngutil.c:50:3: warning: 'sig_bytes' is deprecated (declared at /usr/include/png.h:1255)
make[2]: *** [xvidcap-mngutil.o] Error 1
make[2]: Leaving directory `/home/amigo/Downloads/xvidcap/xvidcap-1.1.3-p7/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/amigo/Downloads/xvidcap/xvidcap-1.1.3-p7'
make: *** [all] Error 2
User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#755 Post by technosaurus »

amigo wrote:

Code: Select all

mngutil.c:36:13: error: conflicting types for 'png_save_uint_16'
/usr/include/png.h:2823:1: note: previous declaration of 'png_save_uint_16' was here
I assume one was unsigned short and the other an equivalent typedef'd uint type

BTW, I'm taking a grad school class where I have to pick an open source project to do "non-programming" work for. I have it narrowed down to 1 of:
libxcb (mostly documentation )
netsurf/nsfb (testing, bug reporting and documentation)
musl-libc (documentation, testing)
toybox (documentation, testing)
(any other projects I'm interested in would involve code contributions)

any feedback? I'm leaning toward xcb because it lacks the documentation required to port major toolkits from x11 ... perhaps a replacement for tinyX11?
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#756 Post by goingnuts »

I am using png-1.2.46 and gcc-3.4.3. Used same patch for 1.1.3 as for 1.0.19 to get pass the conflicting png errors. patch for building xvidcap-1.3.0 in P412
Last edited by goingnuts on Mon 09 Sep 2013, 15:57, edited 2 times in total.
goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#757 Post by goingnuts »

BTW, I'm taking a grad school class where I have to pick an open source project to do "non-programming" work for. I have it narrowed down to 1 of:
libxcb (mostly documentation )
netsurf/nsfb (testing, bug reporting and documentation)
musl-libc (documentation, testing)
toybox (documentation, testing)
(any other projects I'm interested in would involve code contributions)

any feedback? I'm leaning toward xcb because it lacks the documentation required to port major toolkits from x11 ... perhaps a replacement for tinyX11?
@technosaurus: xcb seems to be a very good choice...
goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#758 Post by goingnuts »

xplanet compiles fine as a static linked bin. It gets quite big so cant post package here.
But again I hit the problem with rootwindow being total covered by other apps. In P412 its ROX who prevent a range of applications which write to rootwindow. ROX-1.2 seems not to do this.
jwm newer than 2.1 seems to do the same - covers up rootwindow - and I haven't been able to spot where in the ChangeLog this happened...
Would be so nice if jwm would allow rootwindow to be seen - and same thing for ROX above gtk1.2 versions.
xdesktopwaves mentioned in some post back contains code for writing to backdrop if needed.
Anyway the xplanet is a cool toy for having a more dynamic wallpaper.
amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#759 Post by amigo »

Thanks for the xvidcap patch -sorry I hadn't seen the recent replies. xplanet is nice.
goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#760 Post by goingnuts »

No problem - the patch will not work if embedded ffmpeg is chosen.
Also think that for convenience it should be compiled with that feature enabled to be able to capture and create video in one operation and it does not remove the feature of doing videos from images. I will update my xvidcap-package in near future...

I have to confess I have been wrong about jwm covering rootwindow :oops: Some snapshots might have had this behavior but a lot of them works fine.

I have just compiled latest jwm (868) and must say: I am impressed!
xplanet, conky, mplayer, xdesktopwaves, xvidcap etc. just works! And the sticky windows in pager is also gone. Bravo! :)
Post Reply