strider_mt2k

I jumped right into using THe Go!Go! utility when I got my TH55, but when I disabled and removed it, I found that my video performance was a bit better when viewing videos and when playing games, (TouchTetris comes to mind.)

The two features I was really using were the capture button as power and lens cover alarm, but I think I might learn to live without if it means a performance hit.

The TH needs all of it's horsepower to do it's thing I guess.


Any way to avoid this hit, or is it simply the trade off for the functions?

Dags

It's what I've been saying for months.

Use Default Capture if you want the capture button as power on / off. It doesn't have a hit on performance either.

http://muchy.com/review/defaultcapture.html

Click the big link at the top that says Default Capture 2.0 to grab this one.

__________________
Dags
Japanese Clie/Palm/Tapwave User
(Vx - m505/J - 750C/J - NR70/J - NX80V/J - TH55/J - T|T3.5 - Zod1 - Zod2)

strider_mt2k

Sorry, but I still see some effect even using Default Capture.

It is extremely cool though.

Joel

I have removed TheGoGo a long time ago. I don't mind having the power button where it originally is.

DonWon

the power button is fine with me too, but i need the 4th hard button.
the data assistant button is useless.

Ken

Use TheGoGo to remap the 4th hard button. Then delete TheGoGo. Even after TheGoGo is deleted, the 4th hard button will keep the setting that you assigned to it. I keep TheGoGo archived on my memory stick just in case I want to remap the 4th hard button to something else later.

JulianL

Interesting. Do you notice any difference with battery life? The thing I've found about battery life is that the type of apps I run has a huge effect (far more than my backlight setting). 10 minutes of playing Bejewelled drains the battery about as much as 45 minutes of ebook reading.

If TheGoGo is slowing stuff down then one possible reason is that it's burning CPU cycles in the background. If this is so then maybe there is also a beneficial affect on battery life from removing it. Has anyone noticed this or is the effect too small to notice (or zero)?

- Julian

Sharkk717

If TheGoGO is really slowing down performance then it's probably not running the way i expected it was (which is also the way i implemented SharkButton, which has no performance issues). It's really odd, because i can't think of another way to do what thegogo does. Strange...

__________________
Ludus Technologies
LudusW, SharkMsg, SharkLinks, SharkBtn, SharkSwipe, SharkNav, SharkCache, SharkROM.

What's next? Shark(insert word here).

CliePet

TheGOGO does many different things. The two features discussed here:
#1: mapping the buttons to launch programs. This is using Prefs settings that are stored even after you delete the "TheGoGo" app. There is no performance lost for this feature, but it is limited to those buttons with system-level remapping capabilities [ie. not all of them]

#2: trapping other hardware keys and doing special things with them (like the voice record button? and lens cover check). This requires a program running in the background (like the old-style 'hack manager' hacks), that examines every event going through the system. This can slow things down considerably.

Cyker

Yup. Haktastic
I suspect OS5 Hacks will degrade performance a lot because it is very expensive to perform lots of context switches between 68k and ARM code, and since you HAVE to use ARM code for OS5 hacks...
I mainly installed TheGoGo! for the button mapping. I keep it installed but just disabled.

JulianL

Accepting that people are presumeably only guessing on how TheGoGo behaves (unless the author or someone with access to the source code replies), I'm interested to understand in my own mind the performance (and to me more importantly the power drain) implications of TheGoGo.

Following on from CliePet's description above (and sorry for being a bit pedantic), is it strictly true to say that TheGoGo is "running in the background" (i.e. as a seperate process or thread that is running concurrently with the foreground application via timeslicing), or do you really mean that TheGoGo has somehow hooked some of its own code into the system event handler code so that everytime an event is processed then this extra code gets called. I accept that this could be called "running in the background", but I'm just trying to make sure I understand exactly what is meant.

Assuming that there is extra code hooked into the system event handler then the extra overhead that TheGoGo introduces will be related to the number of events per second that are being generated while an application is running. Assuming I haven't already drifted away from the truth due to my lack of knowledge of PalmOS internals, then the final thing that I am trying to understand is what sort of volume of system events are generated by something like Palm reader (ereader) vs something like Bejewelled.

Would I be correct in thinking that while reading an ebook there are pretty much no events being generated so TheGoGo isn't really an issue until I move the jog dial to generate an event, and maybe the odd timer event going off to make sure that alarms continue to work? When the jog dial is touched, does this generate just a single event or will other events happen as a consequence of ereader then doing screen redraws?

How about something like Bejewelled? Will the complex screen redraw logic after each move tend to generate a lot of events?

- Julian

Sharkk717

>TheGoGo has somehow hooked some of its own code into the system event handler code so that everytime an event is processed then this extra code gets called.

That's the one ;-). It's not so much hooked in, so to say. It's more like TheGoGO has told POS to notify it whenever there is a button pressed. Then, when a button IS pressed, thegogo checks which button it is and redirects you accordingly. TheGoGO only traps virtual chars (basically, buttons and the like), so it's tie in code wouldn't be called on a screen redraw. Again, this is a bit "quick and rough", and maybe CliePet will have further commentation.

__________________
Ludus Technologies
LudusW, SharkMsg, SharkLinks, SharkBtn, SharkSwipe, SharkNav, SharkCache, SharkROM.

What's next? Shark(insert word here).

JulianL

Thanks SharkBoy, you've moved my understanding forward a lot. One question/observation though, if it only traps virtual chars, i.e. no screen redraws, then I wonder why strider and others see a performance degredation of video playback, which surely is all screen redraws. Is it possible that there is a flaw in the implementation of TheGoGo and maybe it inadvertently requests notification on events other than just virtual chars?

- Julian

johntao

since GoGo slows down the Clie.....any other programs out there that can assign the hard buttons?