Beuty vs efficency

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Beuty vs efficency

mavrothal
I build a Slacko 5.7 version for the XO-1 and XO-1.5 and I was struck by the performance hit on the xdialog apps.
Running side by side a Lucid 5.2.5 and Slacko-5.7 in 2 identical XO-1s, Slacko was slower about 3 fold!
It took 3 seconds to open bootmanager 4sec for fontmanager  5sec for eventmanager!. This can not be attributed to newer/heavier infrastructure since other apps were hardly 20% slower in slacko taking 5 sec for abiword and gnumeric and 2.5 seconds for gnome-mplayer and mtpaint.
Granted,  the XO-1 is a really slow machine (400MHz CPU 256MB RAM) and in a semi-dissent (1.5GHz+) machine it goes unnoticed, but still I was wondering if there is anything in the newer gtkdialog or the specific implementation that slows down gtkdialog apps that much and if this could be improved in some way.
Reply | Threaded
Open this post in threaded view
|

Re: Beuty vs efficency

zigbert
My first assumption is the svg gradients made by /usr/lib/gtkdialog/xml-info.
Check out line 40:
       [ ! "$MODE" ] && MODE="gradient" #drawing mode
change mode to 'flat'

Reply | Threaded
Open this post in threaded view
|

Re: Beuty vs efficency

mavrothal
Yes, this improved things by 20-30%, depending on the app.
Anything else that I could try?
Reply | Threaded
Open this post in threaded view
|

Re: Beuty vs efficency

zigbert
Great. I will update to use no gradients by default.

There has been mentioned earlier that gtkdialog reads faster code if comes from a file than from a variable (most common in Woof). I thought this was fixed by Thunor, but if still valid, the latest Slacko will hurt since my gui-code is more complex than the original.

To test this you can replace line 302 in /usr/sbin/eventmanager from
RETSTRING="`gtkdialog -p Puppy_Event_Manager`"
to
echo "$Puppy_Event_Manager" > /tmp/Puppy_Event_Manager
RETSTRING="`gtkdialog -f /tmp/Puppy_Event_Manager`"


Sigmund
Reply | Threaded
Open this post in threaded view
|

Re: Beuty vs efficency

mavrothal
No, this did not make any difference.
Reply | Threaded
Open this post in threaded view
|

Re: Beuty vs efficency

JakeSFR
Also, now (almost?) all scripts are i18n-ed, so it surely increases the start-up time a bit. E.g. 'eventmanager' in Lupu isn't gettext'ed.

# time for i in {0..100}; do echo test >/dev/null; done

real	0m0.006s
user	0m0.007s
sys	0m0.000s

# time for i in {0..100}; do echo `gettext 'test'` >/dev/null; done

real	0m0.336s
user	0m0.017s
sys	0m0.070s

Greetings!
Reply | Threaded
Open this post in threaded view
|

Re: Beuty vs efficency

mavrothal
Gettext does add to the time and actually proportionally to the length of the strings, but not that much.
Besides, adding or not it  *should* be there.
Reply | Threaded
Open this post in threaded view
|

Re: Beuty vs efficency

zigbert
In reply to this post by mavrothal
I fired up my slowest pc - an Asus EEE netbook with the slow Atom processor (1Ghz). I compared the eventmanager in Lupu-5.28, Slacko-5.6 and Slacko-5.7.

Non-graphics features
5.2:
5.6: gettext
5.7: gettext, icons-placement, gui-scaling, correct checkbox status

Startup time
5.2: 0.58 sec
5.6: 0.78 sec
5.7: 1.56 sec

Beauty cost
0.36 sec: Gradient in headings
0.07 sec: Icons in headings
0.00 sec: Borders, markups and margins gave no noticeable speedup.

0.08 sec: correct checkbox status
This gives the checkboxes in 'show icons' tab the correct status, and has an effect on startup time. This could be improved, but has nothing to do with the discussion of beuty vs efficency

Running 5.7 without any information text gives startup-time of 0.68 while showing the info just as in 5.2 (as a simple textstring) has nearly no speed effect compared to the flat yellow heading.

I also tried to skip the <notebook> widget in favor to a simple <vbox>, but I couldn't see any difference in speed.
I have not compared xpm images to svg.

My conclusion is that the general complexity of the gtkdialog code has a big impact on the render-time. - No surprise... But what widgets we use has not the same effect.
Another delay is of course the way I have designed the pixmap/button icons-settings which aren't hardcoded, but sent via /usr/lib/gtkdialog to unify the look. And to give us the ability of touchscreen support without code all guis twice.

Changing background-mode to flat for headings and improve the checkbox status code, I think we could end up with a startup-time for the Eventmanager around 1.12 sec.
Reply | Threaded
Open this post in threaded view
|

Re: Beuty vs efficency

mavrothal
This is probably thunor's territory but I was wondering if compiling the /usr/lib/gtkgialog/* files and integrating into gtkdialog would improve efficiency.
Reply | Threaded
Open this post in threaded view
|

Re: Beauty vs efficency

scsijon
In reply to this post by mavrothal
Except their not in that directory in all versions of puppy to start with.

On 03/16/2014 03:57 PM, mavrothal [via woof-CE] wrote:
>
>
> This is probably thunor's territory but I was wondering if compiling the
> /usr/lib/gtkgialog/* files and integrating into gtkdialog would improve
> efficiency.
>
Reply | Threaded
Open this post in threaded view
|

Re: Beauty vs efficency

01micko
Administrator
scsijon wrote
Except their not in that directory in all versions of puppy to start with.
They are in all woof-CE versions. Since last year.
Reply | Threaded
Open this post in threaded view
|

Re: Beuty vs efficency

zigbert
In reply to this post by mavrothal
I don't think it is the /usr/lib/gtkdialog/* that gives the delay, but my extended code and gtkdialog itself.
Eventmanager in 5.6 and 5.2.8 generates 6176 bytes for gtkdialog to render, while the one in Woof generates 17613 bytes... And gtkdialog is a slow engine.

Please be aware that I use Eventmanager as the example because this gives the largest speed penalty in 5.7 compared to 5.6. Most guis in 5.7 has larger gtkdialog-code than 5.6 because of the scaling feature, but far from the gap that we see in Eventmanger. The byte-count of ie. alsawizard is 4523 in Woof-CE.

I think the most important discussion here is:
- What are the minimum requirements for Puppy? The Slacko release-notes states: 900MHz processor (P3 or AMD K7), 512MB RAM.
- What is an acceptable startup delay?

If our target is fastest as possible we are sure on the wrong track.
- We should use only compiled software
- We should use gtk1, fltk, ...
- We should not support internationalization.
- We should not use top-layer themes or graphics.
Reply | Threaded
Open this post in threaded view
|

Re: Beuty vs efficency

01micko
Administrator
Sorry for slight OT, needed a "paste bin" for Pcur

#!/bin/sh
#(c) copyright Barry Kauler aug 2009. Licence LGPL.
#120202 rodin.s: i18n
#121020 fix msg where locate 'cursor_themes' pet pkg.

export TEXTDOMAIN=pcur
export OUTPUT_CHARSET=UTF-8
CURLIST=""
FIRSTITEM=""
LISTHEIGHT=50
PREVTHEME=""
[ -e $HOME/.icons/default ] && PREVTHEME="`readlink $HOME/.icons/default | rev | cut -f 1 -d '/' | rev`"
mkdir -p /tmp/xcur2png

func_switch (){
	ln -snf "$1" $HOME/.icons/default
	[ "$(</etc/windowmanager)" = "jwm" ] && jwm -restart
}
export -f func_switch

func_download (){
	REPO=http://distro.ibiblio.org/puppylinux/pet_packages-noarch
	PKG=`grep -iE "cursor_themes" ~/.packages/Packages-puppy-noarch-official|awk -F'|' '{print $8}'`
	download_file ${REPO}/${PKG}
	[ $? -ne 0 ] && gtkdialog-splash -bg red -text "failure" && exit 1
	petget +${PKG}
	[ $? -ne 0 ] && gtkdialog-splash -bg red -text "failure" && exit 1
	rm $PKG
	gtkdialog-splash -bg green -text "Success" && exit 0
	#replace failure and success with a box-splash message? 'try again' or 'please restart Pcur'
}
export -f func_download

for ONEITEM in `ls -1 $HOME/.icons | grep -v 'ROX'`; do
	#precaution that 'cursors' subdir exists...
	[ ! -d $HOME/.icons/${ONEITEM}/cursors ] && continue
	if [ ! -f /usr/share/icons/${ONEITEM}.png ]; then
		cd $HOME/.icons/${ONEITEM}/cursors
		xcur2png -d /tmp/xcur2png left_ptr
		mv -f /tmp/xcur2png/left_ptr_000.png /usr/share/icons/${ONEITEM}.png
		rm -f /tmp/xcur2png/left_ptr_*.png
	fi
 
	if [ "$ONEITEM" = "$PREVTHEME" ]; then
#		FIRSTITEM="<item icon=\"${ONEITEM}\">${ONEITEM} CURRENT THEME</item>"
		FIRSTITEM="<item icon=\"${ONEITEM}\">${ONEITEM}</item>"
	else
		CURLIST="${CURLIST}<item icon=\"${ONEITEM}\">${ONEITEM}</item>"
	fi
	LISTHEIGHT=`expr $LISTHEIGHT + 25`
done

[ $LISTHEIGHT -gt 550 ] && LISTHEIGHT=550
CURITEMS='
<tree>
  <label>'$(gettext 'Cursor theme')'</label>
  '${FIRSTITEM}'
  <item icon="default_left_ptr">ORIGINAL THEME</item>
  '${CURLIST}'
  <variable>CHOOSECUR</variable>
  <height>'${LISTHEIGHT}'</height>
  <action>func_switch "$CHOOSECUR"</action>
</tree>'
  
if [ "$CURLIST" = "" ]; then
	TXT="$(gettext "<b>No themes found.</b> Install one from the Puppy Package Manager. Find the 'cursor_themes' package in the 'Desktop' category of the 'puppy-noarch' repository.")"
	#CURITEMS=''
	CURITEMS='<frame><hbox space-fill="true" space-expand="true"><text><label>Hit this button to download</label></text>
	<button><label>Download</label><action>func_download &</action><action type="exit">exit</action></button></hbox></frame>'
elif [ "$(</etc/windowmanager)" != "jwm" ]; then
	TXT="<b>$(gettext 'You must restart X to use the new theme.')</b>"
else
	TXT="$(gettext '<b>Choose your prefered mousepointer theme.</b> Themes are installed to') $HOME/.icons."
fi

export Pcur='
<window title="'$(gettext 'Pcur - Cursor theme setter')'">
<vbox space-fill="true" space-expand="true">
  '"`/usr/lib/gtkdialog/xml_info fixed mouse_cursor.svg 60 "$(gettext "$TXT")"`"'
  <vbox space-fill="true" space-expand="true">
    '${CURITEMS}'
   <hbox space-expand="false" space-fill="false">
      <button space-expand="false" space-fill="false">
        <label>'$(gettext "Apply")'</label>
        '"`/usr/lib/gtkdialog/xml_button-icon apply`"'
        <action>func_switch "$CHOOSECUR"</action>
      </button>
      <button space-expand="false" space-fill="false">
        <label>'$(gettext "Ok")'</label>
        '"`/usr/lib/gtkdialog/xml_button-icon ok`"'
        <action>func_switch "$CHOOSECUR"</action>
        <action>exit:quit</action>
      </button>
      <button space-expand="false" space-fill="false">
        <label>'$(gettext "Quit")'</label>
        '"`/usr/lib/gtkdialog/xml_button-icon quit`"'
        <action>exit:quit</action>
      </button>
    </hbox>
  </vbox>
</vbox>
</window>'
. /usr/lib/gtkdialog/xml_info gtk #build bg_pixmap for gtk-theme
RETVARS="`gtkdialog -p Pcur`"

[ "$CURLIST" = "" ] && exit
echo "$RETVARS"
eval "${RETVARS}"

[ "$EXIT" != "OK" ] && exit
[ "`echo "$CHOOSECUR" | grep 'CURRENT THEME'`" != "" ] && exit #already current.

if [ "$CHOOSECUR" = "ORIGINAL THEME" ]; then
	rm -f $HOME/.icons/default
	exit
fi

NOTES:
* the function_download works fine; replace splash with box_splash
*
TXT="$(gettext "<b>No themes found.</b> Install one from the Puppy Package Manager. Find the 'cursor_themes' package in the 'Desktop' category of the 'puppy-noarch' repository.")"
	#CURITEMS=''
	CURITEMS='<frame><hbox space-fill="true" space-expand="true"><text><label>Hit this button to download</label></text>
	<button><label>Download</label><action>func_download &</action><action type="exit">exit</action></button></hbox></frame>'
Obviously words need adjustment and the button of course
* Thoughts?

Reply | Threaded
Open this post in threaded view
|

Re: Beuty vs efficency

mavrothal
In reply to this post by zigbert
The minimum machine specs are if anything low and we certainly want gettext, gtk2 etc.
The issue is if there is anyway to keep the considerably better look and improve on the performance penalty.

Even in a medium machine (1.6GHz/768 MB) the difference between 5.6 and 5.7, although not bothersome is noticeable. If there is no way to improve that so be it. If there is, either at the gtkdialog level or the xml coding or the images or ...,  it certainly worth trying.

Puppy *is* established among other things, for its perceived speed. Mostly due to ROX/JWM and its many (small) gtkdialog apps that open instantly. Would be nice if we could keep this perception alive.
Reply | Threaded
Open this post in threaded view
|

Re: Beuty vs efficency

zigbert
I agree
Reply | Threaded
Open this post in threaded view
|

Re: Beuty vs efficency

Iguleder
Can't we create a cache of scaled PNG images created from the SVG icons? I mean, libstardust could convert each SVG icon to a PNG one in /var/cache, when it's displayed for the first time.