Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[m2kio]

presumably with wxMac 2.6.0 the behavior of aMule on a loaded system worsened noticably:
when cpu load goes to full load for a certain while, e.g. when compiling or even scrolling within amule then UL and DL stall dramatically and most connections get disrupted after a short time. with wxMac 2.5.x there was a certain drop in the UL rate when cpu usage was high for a prolonged time too, but it was far not as severe as it is now.

yes, i know, it's probably to blame on wxMac.  X(

m2kio !

[m2kio]

just an update to this:

now on OSX10.4 Tiger:

a generally loaded system does not longer affect UL/DL performance (still a little bit, but 'as expected'). So it has been fixed 'by Apple'.

only if aMule get's heavily loaded itself, especially when scrolling in the shared files list (~110 files) then UL still drops dramatically, for DL i can't tell, i do not have any DL right now.

Q: is it possible to merge mouse scroll-wheel events? that would help here a lot. you cannot imagine how painful it is to see amule scrolling for 15 secs at 100% cpu load...

... m2kio !

[ken]

Hi m2kio,

I too have noticed the very weird behavior of aMule in response to the scroll-wheel.  If I give the wheel a large/fast spin, the scrolling can go on for several seconds in jumps separated by significant pauses.  It's very strange and unpleasant.  

I know scroll-wheel never worked for you until relatively recently, but it did for some of us a while ago, then it stopped working, and now we have this.  Although it was never what I would consider to be "snappy", I can tell you that when it worked before, it was much, much better than this.  I believe the problem resides in wxMac because, basically, aMule itself is ignorant of scroll-wheel events.

Anyway, the reason that upload throughput drops is that in aMule network communication generally happens on the same thread as user interface handling.  So, if it takes a long time to scroll or redraw the download lists, then that is time that can't be spent processing network communications.  Unless this persists for quite a while, I wouldn't expect connections to be dropped.

Personally, I generally avoid using the scroll-wheel except for 1 or 2 line scrolling.  Sorry I can't offer anything better for now.

[ken]

Well, I think I've tracked the problem down.

When you give the scroll-wheel a large spin, the OS generates a few events, each saying something like "scroll 50 units down".  However, wxWidgets only has an internal event for "scroll 1 line down".  So, it translates each scroll-wheel event from the system into many events internally.  :rolleyes:

Well, that's bad enough, to incur 50 times the overhead of message processing.  However, in most cases, when you scroll a window you actually do a graphical bit copy of that part of the currently visible area that will still be visible after the scroll to its new location.  For a 1 line scroll down, this means you will copy most of the window contents 1 line's height up and request a redraw of just the 1 newly scrolled-in line.  For 50 1-line scrolls in a row, that means you have copied most of the window contents 50 times over and then have to redraw almost all of it anyway.  8o

The proper solution is to give wxWidgets the notion "scroll X lines down".  However, that's not backward compatible with existing wxWidgets-based programs, so no patch I might submit will be accepted in the near term.

wxWidgets does provide a mechanism for skipping the graphic bit copying normally done during scrolling, but it has limitations that I'm still trying to work around.  I'm also looking into ways to implement a custom "scroll X lines down" event that's local to aMule.

By the way, the reason you don't see all this graphical copying as flicker on the screen is because Mac OS X automatically double-buffers all windows.  Their contents are only drawn to screen when the program returns to the main event loop, which isn't until after all 50 "scroll 1 line down" messages are processed.

Lastly, I don't know why this problem doesn't affect aMule on all platforms.  The parts of the code I examined were all cross-platform, I think.  It is true that wx's list drawing seems slower on the Mac in general, so maybe this is just a magnification of that effect.  Or maybe other platforms don't bother with the bit copying when scrolling.

[m2kio]

hi Ken,

i assume wxMac simply does no bit copying when scrolling, i assume they redraw the whole list with the new offset. but this is guessing.

if you can intercept the mouse wheel event before it is passed to the scroll list widget and if you can query & peek into the next event, then you could combine multiple scroll wheel events and handle them in a new multi-line scroll event handler.

i assume that those list views in amule are derived from wxWidgets' list view widget anyway, so what's left is whether you can preview the next event.

... m2kio !

[ken]

No, m2kio, you misunderstand.  The scroll-wheel events are already grouped.  The events which are separated out are the "scroll by 1 line" events, which aren't scroll-wheel specific.  These are the same events delivered when you tap the arrows at the ends of the scrollbars.  And anyway, they never exist on any sort of event queue, they are generated programatically and immediately dispatched.  The next event isn't generated until after the first one is processed.  So, there's no way to peek ahead and see if there more coming because there isn't any queue in which to look.