Wine 20050310 redraw problems (specifically with Paint Shop Pro 7)
I remember posting about this quite a while ago but decided to revisit it, and it seems like it's still an issue in the 20050310 build of wine. Wine has real trouble with refreshing drawing surface windows in Paint Shop Pro 7: - the background in a new image window isn't cleared - tools that display tooltips (such as the colour selector control) leave tooltip debris all over the drawing surface when they're moved around. - drawing surface isn't refreshed if partially / totally obscured by other windows and then made visible again. Normal windows, dialogs etc. are working fine (and tooltips work fine too above normal controls) - it would seem that the drawing surfaces in PSP7 are handled differently (presumably for speed reasons) and wine is having some serious problems handling them. Any ideas for a workaround / patch, or is this bug known about and in the pipeline to be sorted out? I've exhausted various options in the Wine config file to do with display output; the problem seems to be in core code somewhere. I get the following error message at startup as follows: fixme:ole:CoRegisterMessageFilter stub followed by several: err:region:CombineRgn Invalid rgn=(nil) ... the latter used to happen an awful lot in earlier wine builds whilst the app was being used, but note that it's *not* happening with the 20050310 build whilst I try and use the app; only at startup time. (In other words, it's quite possibly not related to the redraw issues at all) Any ideas? PSP7 is so "almost there" that it'd be a shame if it wasn't 100%... Happy to provide further details if someone gives me instructions as to what to look at! cheers Jules
On Tue, May 03, 2005 at 02:33:56PM +0000, Jules Richardson wrote:
I remember posting about this quite a while ago but decided to revisit it, and it seems like it's still an issue in the 20050310 build of wine.
Please use 20050419 at least, a huge amount of changes went into the respective code. Ciao, Marcus
On Tue, 2005-05-03 at 16:54 +0200, Marcus Meissner wrote:
On Tue, May 03, 2005 at 02:33:56PM +0000, Jules Richardson wrote:
I remember posting about this quite a while ago but decided to revisit it, and it seems like it's still an issue in the 20050310 build of wine.
Please use 20050419 at least, a huge amount of changes went into the respective code.
Just done so (using 20050419 built from source) - unfortunately no change; same behaviour (including the null pointer CombineRgn errors, which may or may not be related) If there's anything I can do to get some meaningful debug out of things to help diagnose the actual root problem, let me know - I'd assume that whatever trick PSP uses to do efficient drawing is also used in other Windows apps, so no doubt a fix (or at least understanding of the basic problem) would prove useful elsewhere too... ps. your own message arrived in my inbox before my original email was even echoed back - now that's efficiency! :-) cheers Jules
I'll second that. I have a small win32 app that I wrote years ago in Delphi 2. It had some fancy redrawing to give rounded degraded borders to windows. This completely locks up on recent wine versions. On Tue, 03 May 2005 18:16:26 +0200, Jules Richardson <julesrichardsonuk(a)yahoo.co.uk> wrote:
On Tue, 2005-05-03 at 16:54 +0200, Marcus Meissner wrote:
On Tue, May 03, 2005 at 02:33:56PM +0000, Jules Richardson wrote:
I remember posting about this quite a while ago but decided to revisit it, and it seems like it's still an issue in the 20050310 build of wine.
Please use 20050419 at least, a huge amount of changes went into the respective code.
Just done so (using 20050419 built from source) - unfortunately no change; same behaviour (including the null pointer CombineRgn errors, which may or may not be related)
If there's anything I can do to get some meaningful debug out of things to help diagnose the actual root problem, let me know - I'd assume that whatever trick PSP uses to do efficient drawing is also used in other Windows apps, so no doubt a fix (or at least understanding of the basic problem) would prove useful elsewhere too...
ps. your own message arrived in my inbox before my original email was even echoed back - now that's efficiency! :-)
cheers
Jules
On Tue, 2005-05-03 at 16:16 +0000, Jules Richardson wrote:
On Tue, 2005-05-03 at 16:54 +0200, Marcus Meissner wrote:
On Tue, May 03, 2005 at 02:33:56PM +0000, Jules Richardson wrote:
I remember posting about this quite a while ago but decided to revisit it, and it seems like it's still an issue in the 20050310 build of wine.
Please use 20050419 at least, a huge amount of changes went into the respective code.
Just done so (using 20050419 built from source) - unfortunately no change; same behaviour (including the null pointer CombineRgn errors, which may or may not be related)
Right, bit of an update. Wine 20040914 built from the source distribution at ftp://metalab.unc.edu/pub/Linux/ALPHA/wine/development *works* (so I have a solution for my specific problem at least) Wine 20040914 *binary* distribution from WineHQ.org for Slackware 10, as I originally tried last year, used to have all sorts of redraw faults - however I've upgraded both video card and X distribution then, so I'm willing to say one of those cured it. Wine 20050211, 20050310, 20050419 (the three I've tried) all have this nasty redraw bug where the drawing canvas isn't being refreshed. So whatever the fault is, it crept in somewhere between 20040914 and 20050211. If I get chance (it doesn't take long to build from source after all) I'll see if I can pinpoint exactly what release first had the bug and let the list know... cheers Jules
On Thu, 2005-05-05 at 10:34 +0000, Jules Richardson wrote:
Wine 20050211, 20050310, 20050419 (the three I've tried) all have this nasty redraw bug where the drawing canvas isn't being refreshed. So whatever the fault is, it crept in somewhere between 20040914 and 20050211.
Right, whatever the problem is, it turned up in 20050111. Versions prior to that handled the window creation / refresh correctly, but at 20050111 and later the window isn't being cleared upon initial creation and isn't being refreshed when the window is partially or wholly obscured by anything and then made visible again. Note that PSP drawing tools *do* work - i.e. I can draw with the pen tool say, and the window contents are updated fine. It seems to be interaction with "external" things (tooltips, other windows etc.) that has been broken. Unless someone can point me at how to get a call trace out of Wine (one that isn't several GB :-) this is about at the limit of what I can do though - my C coding is rather rusty and I likely don't have the time to read up on how the debugger etc. work. Doubtless a call trace would be useful in pinpointing the problem though... cheers Jules
Looks like something I'm messing around right now. Give me few more hours I'll have a patch for you to try. Best regards, Vitaliy Thursday, May 5, 2005, 10:32:52 AM, you wrote:
On Thu, 2005-05-05 at 10:34 +0000, Jules Richardson wrote:
Wine 20050211, 20050310, 20050419 (the three I've tried) all have this nasty redraw bug where the drawing canvas isn't being refreshed. So whatever the fault is, it crept in somewhere between 20040914 and 20050211.
Right, whatever the problem is, it turned up in 20050111.
Versions prior to that handled the window creation / refresh correctly, but at 20050111 and later the window isn't being cleared upon initial creation and isn't being refreshed when the window is partially or wholly obscured by anything and then made visible again.
Note that PSP drawing tools *do* work - i.e. I can draw with the pen tool say, and the window contents are updated fine. It seems to be interaction with "external" things (tooltips, other windows etc.) that has been broken.
Unless someone can point me at how to get a call trace out of Wine (one that isn't several GB :-) this is about at the limit of what I can do though - my C coding is rather rusty and I likely don't have the time to read up on how the debugger etc. work. Doubtless a call trace would be useful in pinpointing the problem though...
cheers
Jules
Ok try this. Not perfect, but the move in the right direction. Thursday, May 5, 2005, 12:59:22 PM, you wrote:
Looks like something I'm messing around right now. Give me few more hours I'll have a patch for you to try.
Best regards, Vitaliy
Thursday, May 5, 2005, 10:32:52 AM, you wrote:
On Thu, 2005-05-05 at 10:34 +0000, Jules Richardson wrote:
Wine 20050211, 20050310, 20050419 (the three I've tried) all have this nasty redraw bug where the drawing canvas isn't being refreshed. So whatever the fault is, it crept in somewhere between 20040914 and 20050211.
Right, whatever the problem is, it turned up in 20050111.
Versions prior to that handled the window creation / refresh correctly, but at 20050111 and later the window isn't being cleared upon initial creation and isn't being refreshed when the window is partially or wholly obscured by anything and then made visible again.
Note that PSP drawing tools *do* work - i.e. I can draw with the pen tool say, and the window contents are updated fine. It seems to be interaction with "external" things (tooltips, other windows etc.) that has been broken.
Unless someone can point me at how to get a call trace out of Wine (one that isn't several GB :-) this is about at the limit of what I can do though - my C coding is rather rusty and I likely don't have the time to read up on how the debugger etc. work. Doubtless a call trace would be useful in pinpointing the problem though...
cheers
Jules
Didn't work I'm afraid - no change (patched 20050419 source) Exactly the same behaviour as before, for what it's worth! It's getting late here, but I can glady try anything else you might come up with tomorrow! Oh, I turned on trace debug for both 20041201 (last version that works) and 20050111 (where the problem first shows up). There's nothing obviously different between the two; the same things seem to be called, in the same order etc. If the problem's likely to be in x11drv then I can do some poking around tomorrow; a diff between the source for 20041201 and 20050111 might give some clues as to what's happening... cheers Jules On Thu, 2005-05-05 at 15:13 -0600, Vitaliy Margolen wrote:
Ok try this. Not perfect, but the move in the right direction.
Thursday, May 5, 2005, 12:59:22 PM, you wrote:
Looks like something I'm messing around right now. Give me few more hours I'll have a patch for you to try.
Best regards, Vitaliy
Thursday, May 5, 2005, 10:32:52 AM, you wrote:
On Thu, 2005-05-05 at 10:34 +0000, Jules Richardson wrote:
Wine 20050211, 20050310, 20050419 (the three I've tried) all have this nasty redraw bug where the drawing canvas isn't being refreshed. So whatever the fault is, it crept in somewhere between 20040914 and 20050211.
Right, whatever the problem is, it turned up in 20050111.
Versions prior to that handled the window creation / refresh correctly, but at 20050111 and later the window isn't being cleared upon initial creation and isn't being refreshed when the window is partially or wholly obscured by anything and then made visible again.
Note that PSP drawing tools *do* work - i.e. I can draw with the pen tool say, and the window contents are updated fine. It seems to be interaction with "external" things (tooltips, other windows etc.) that has been broken.
Unless someone can point me at how to get a call trace out of Wine (one that isn't several GB :-) this is about at the limit of what I can do though - my C coding is rather rusty and I likely don't have the time to read up on how the debugger etc. work. Doubtless a call trace would be useful in pinpointing the problem though...
cheers
Jules
-- "We've had a lot of loonies around this place, but you're the first one who thought the sunrise was made out of stale beer. Now are you going to pick up your flute and leave, or shall I part your hair with this crowbar?"
On Thu, 2005-05-05 at 23:39 +0000, Jules Richardson wrote:
If the problem's likely to be in x11drv then I can do some poking around tomorrow; a diff between the source for 20041201 and 20050111 might give some clues as to what's happening...
Hmm, well dlls/x11drv/winpos.c and window.c certainly look like possible candidates for the cause of this redraw problem; it seems like a lot of changes went in there between 20041201 and 20050111 related to redraw / region handling according to the changelog. (and of course winpos.c is what Vitaliy's patch from yesterday relates to) It's almost certainly beyond me to try and fix the problem though; I don't understand how Wine works under the covers, how all the files fit together and what each does etc. - I'm happy to test any ideas / patches that anyone might be able to come up with though. cheers Jules
You know, it could be one more place then. Native does RedrawWindow when focus changes. But not always. As soon as I figure out when we need to redraw and when we don't, I'll send you a patch to try. Friday, May 6, 2005, 9:25:45 AM, you wrote:
On Thu, 2005-05-05 at 23:39 +0000, Jules Richardson wrote:
If the problem's likely to be in x11drv then I can do some poking around tomorrow; a diff between the source for 20041201 and 20050111 might give some clues as to what's happening...
Hmm, well dlls/x11drv/winpos.c and window.c certainly look like possible candidates for the cause of this redraw problem; it seems like a lot of changes went in there between 20041201 and 20050111 related to redraw / region handling according to the changelog. (and of course winpos.c is what Vitaliy's patch from yesterday relates to)
It's almost certainly beyond me to try and fix the problem though; I don't understand how Wine works under the covers, how all the files fit together and what each does etc. - I'm happy to test any ideas / patches that anyone might be able to come up with though.
cheers
Jules
On Fri, 2005-05-06 at 09:50 -0600, Vitaliy Margolen wrote:
You know, it could be one more place then. Native does RedrawWindow when focus changes. But not always. As soon as I figure out when we need to redraw and when we don't, I'll send you a patch to try.
Ok :) I've been playing around with the x11drv code a bit here (trying to add "old" code from 20041201 into 20050111) but with limited success as quite a bit changed in that area at that time it seems. Shame there's no obvious way of finding out what triggers the problem (i.e. why the drawing window in PSP doesn't work but other types of windows do) as that might allow you to recreate it there... (there was a downloadable trial version of PSP 7 on the web before, but since Corel bought out JASC all the old downloads have gone...) cheers Jules
I could send you a piece of it (psp7) or even better, upload it to one of your servers....I have also 8.1 if you are interested... Tell me what to do.... Jules Richardson wrote:
On Fri, 2005-05-06 at 09:50 -0600, Vitaliy Margolen wrote:
You know, it could be one more place then. Native does RedrawWindow when focus changes. But not always. As soon as I figure out when we need to redraw and when we don't, I'll send you a patch to try.
Ok :) I've been playing around with the x11drv code a bit here (trying to add "old" code from 20041201 into 20050111) but with limited success as quite a bit changed in that area at that time it seems.
Shame there's no obvious way of finding out what triggers the problem (i.e. why the drawing window in PSP doesn't work but other types of windows do) as that might allow you to recreate it there...
(there was a downloadable trial version of PSP 7 on the web before, but since Corel bought out JASC all the old downloads have gone...)
cheers
Jules
-- Regards Signer: Eddy Nigg Company: StartCom Linux at www.startcom.org <http://www.startcom.org/> MediaHost^(TM) at www.mediahost.org <http://www.mediahost.org/> Skype: startcom <callto://startcom/> Phone: +1.213.341.0390 Import StartCom Public CA <http://cert.startcom.org/index.php?app=109>
On Fri, 2005-05-06 at 09:50 -0600, Vitaliy Margolen wrote:
You know, it could be one more place then. Native does RedrawWindow when focus changes. But not always. As soon as I figure out when we need to redraw and when we don't, I'll send you a patch to try.
The more I think about this, the more it makes sense that the X11 side of things is functioning correctly. I can't find any wine docs (yet) that describe message flow for the windowing system, but I suspect the following (someone shout if I'm definitely right or wrong on this!): Paint Shop Pro will be one of those classes of apps that looks after its own drawing windows, and expects the system to pass *all* window related messages for its drawing window(s) to the app itself, rather than wine trapping and handling some of them. I suspect this is what got screwed up as of the 20050111 release - wine is probably either handling *some* types of window event when it shouldn't, or at the very least isn't passing them on to the application so that the app can respond as it sees fit. That could explain why psp's drawing window isn't cleared when it's created, redrawn when it's moved etc., but that using psp's own drawing tools on the window *does* work... Am I right in thinking that everything in dlls/x11drv/* handles events between wine and the rest of the Unix desktop, whilst everything in windows/* handles the event structure and clipping between wine windows? cheers Jules
That's try this patch: http://www.winehq.com/hypermail/wine-patches/2005/05/0207.html Wednesday, May 11, 2005, 9:17:31 AM, you wrote:
On Fri, 2005-05-06 at 09:50 -0600, Vitaliy Margolen wrote:
You know, it could be one more place then. Native does RedrawWindow when focus changes. But not always. As soon as I figure out when we need to redraw and when we don't, I'll send you a patch to try.
The more I think about this, the more it makes sense that the X11 side of things is functioning correctly. Not really. I have found few things that are not. Some are "wontfix" some are pain to fix.
I can't find any wine docs (yet) that describe message flow for the windowing system, but I suspect the following (someone shout if I'm definitely right or wrong on this!):
Paint Shop Pro will be one of those classes of apps that looks after its own drawing windows, and expects the system to pass *all* window related messages for its drawing window(s) to the app itself, rather than wine trapping and handling some of them. This is up to any app to do. All messages are sent to app in a first place. Then app decides if it will handle the massage or pass it default handler.
I suspect this is what got screwed up as of the 20050111 release - wine is probably either handling *some* types of window event when it shouldn't, or at the very least isn't passing them on to the application so that the app can respond as it sees fit. From what I seen, I could say that wine doesn't send enough messages or sends them out-of-order.
That could explain why psp's drawing window isn't cleared when it's created, redrawn when it's moved etc., but that using psp's own drawing tools on the window *does* work... These are the two things I'm looking at right now. Wine just does not send required messages. So there is nothing for app to handle.
Am I right in thinking that everything in dlls/x11drv/* handles events between wine and the rest of the Unix desktop, whilst everything in windows/* handles the event structure and clipping between wine windows? My understanding is x11drv is more low-level interaction with X. Everything in windows/* belongs to dlls/user. And dlls/user/ is more of a top level type of things. Bellow all of this is server/ that tracks a number of things, but (as I understand) doesn't do anything itself. For example: SetWindowPos is defined in dlls/user/winpos.c, but all it does, is calls X11DRV_SetWindowPos in dlls/x11drv/winpos.c (for console apps it's somewhere else). Then X11DRV_SetWindowPos does the whole work itself, using some information from the server for that.
The problem, as I see it, comes from two places: 1. Wine does not have full implementation of number of things, or it's not correct (good enough for apps people where running when they implemented that part). 2. Interaction with X and window manager (wm) puts some restrictions to what can and can not be done. If certain thing is missing from X then it can't be implemented in wine (like some of OpenGL stuff). Same goes for wm (like handling of WM_MINIMIZE/WM_MAXIMIZE). It requires closer interaction with wm which is not implemented yet.
On Wed, 2005-05-11 at 10:22 -0600, Vitaliy Margolen wrote:
That's try this patch: http://www.winehq.com/hypermail/wine-patches/2005/05/0207.html
No luck I'm afraid, same behaviour :(
Paint Shop Pro will be one of those classes of apps that looks after its own drawing windows, and expects the system to pass *all* window related messages for its drawing window(s) to the app itself, rather than wine trapping and handling some of them. This is up to any app to do. All messages are sent to app in a first place. Then app decides if it will handle the massage or pass it default handler.
Is there a way of trapping and spitting to stdout all the window-related event messages that are being sent to an app? Or do they not happen in any kind of central enough place to do that? (I suppose it'd also be useful to be able to dump all window flags at the same time) At least that way I could see exactly what events the app was getting in 20040914 (where things worked) that suddenly went missing in 20050111... (assuming it is an event handling / window flag bug at all rather than a window stack problem that crept in or something) Not only am I not familiar with the wine source code yet, I've got no clue how the Windows event model even works... :) cheers Jules
Wednesday, May 11, 2005, 1:26:13 PM, you wrote:
On Wed, 2005-05-11 at 10:22 -0600, Vitaliy Margolen wrote:
That's try this patch: http://www.winehq.com/hypermail/wine-patches/2005/05/0207.html
No luck I'm afraid, same behaviour :( That's too bad. I was hopping it would fix you bug. I guess it's somewhere else.
Paint Shop Pro will be one of those classes of apps that looks after its own drawing windows, and expects the system to pass *all* window related messages for its drawing window(s) to the app itself, rather than wine trapping and handling some of them. This is up to any app to do. All messages are sent to app in a first place. Then app decides if it will handle the massage or pass it default handler.
Is there a way of trapping and spitting to stdout all the window-related event messages that are being sent to an app? Or do they not happen in any kind of central enough place to do that? (I suppose it'd also be useful to be able to dump all window flags at the same time) Yes. do WINEDEBUG=+message wine app.exe &> /tmp/log
At least that way I could see exactly what events the app was getting in 20040914 (where things worked) that suddenly went missing in 20050111... (assuming it is an event handling / window flag bug at all rather than a window stack problem that crept in or something) That's hope this is the case. Chasing heap bugs are so much fun ;-)
Not only am I not familiar with the wine source code yet, I've got no clue how the Windows event model even works... :) Good luck on this one.
Vitaliy
On Wed, 2005-05-11 at 14:38 -0600, Vitaliy Margolen wrote:
Is there a way of trapping and spitting to stdout all the window-related event messages that are being sent to an app? Or do they not happen in any kind of central enough place to do that? (I suppose it'd also be useful to be able to dump all window flags at the same time) Yes. do WINEDEBUG=+message wine app.exe &> /tmp/log
Right, message logs of 20041201 (which worked ok) and 20050111 (which doesn't work) are at: http://www.patooie.com/temp/w20041201.w.bx http://www.patooie.com/temp/w20050111.w.bx Load into your favourite visual diff tool and compare :-) These are logs just from the point where I hit the OK button in each build in order for PSP to create a drawing canvas; as soon as the canvas window was visible I hit ctrl-C from the controlling terminal (to avoid lots of shutdown message trace in the logs). So in theory, it's just the relevant bit... ... I've also filtered out WM_MDIGETACTIVE, WM_GETDLGCODE and WM_IDLEUPDATECMDUI as they ate up a lot of log space and didn't seem to related to this redraw problem. All versions after and including wine 20050111 have the redraw bug, but I just picked the next version after the working 20041201 as diff results are more likely to show up what the problem is. Oh, I filtered out all WM_* events and compared them too; there's no "missing" WM_* events from the later code, although my simple checks there wouldn't detect if the order in which things happened changed. Note that the diff output is very similar, apart from a few places where the order of things seems to get swapped around a little (next challenge for me is to figure out which of these messages are relevant and what they mean!). snapshot of the working new image window in 20041201, cleared as it should be with the checkered background: http://www.patooie.com/temp/wine20041201.jpg ... and a snapshot of the broken window as happens in 20050111 and later (not cleared, and with the remains of the 'new image' dialog box still visible): http://www.patooie.com/temp/wine20050111.jpg cheers Jules
Friday, May 13, 2005, 2:14:18 PM, you wrote:
On Wed, 2005-05-11 at 14:38 -0600, Vitaliy Margolen wrote:
Is there a way of trapping and spitting to stdout all the window-related event messages that are being sent to an app? Or do they not happen in any kind of central enough place to do that? (I suppose it'd also be useful to be able to dump all window flags at the same time) Yes. do WINEDEBUG=+message wine app.exe &> /tmp/log
Right, message logs of 20041201 (which worked ok) and 20050111 (which doesn't work) are at:
http://www.patooie.com/temp/w20041201.w.bx http://www.patooie.com/temp/w20050111.w.bx Well, I don't see anything significantly different. I'm afraid you'll need to find the patch that broke it four you see http://www.winehq.com/site/docs/wine-devel/x1316.
The code I'm working on right now has something to do with owner/owned windows and not with MDI windows. Vitaliy
Just to say that I've just tried Wine 20050524 and all the problems are *almost* fixed (20050419 was still broken, so the fixes have crept in since then) A new image in PSP correctly draws/clears itself. Tooltips *almost* clean up after themselves, except when the tooltip's right edge goes over the drawing window's right edge, or the tooltip's bottom edge goes over the drawing window's bottom edge. In those two situations traces of the tooltip get left behind on the image canvas until the display is refreshed manually (desktop switch, dragging another window in front etc.). No problems at the top or left boundaries though, just right / bottom. Pop-up menus behave in exactly the same way as tooltips; they get cleared OK if they're wholly within the image canvas (or overlapping top / left edges), but don't force a redraw when they're overlapping right / bottom margins of the image canvas window. The image canvas now correctly redraws itself when other X or Wine windows obscure it and then move away, or I switch desktops etc. I've seen one total application lockup when moving another X window across the front of the PSP ones managed by Wine, but I need to do some more investigation there to try and figure out what symptoms cause it though. Still, looking good on the whole, so a big thanks to whoever's been messing with the redraw code lately! (Vitaly?) cheers Jules
That's good news! Keep up the good work! Jules Richardson wrote:
Just to say that I've just tried Wine 20050524 and all the problems are *almost* fixed (20050419 was still broken, so the fixes have crept in since then)
A new image in PSP correctly draws/clears itself.
Tooltips *almost* clean up after themselves, except when the tooltip's right edge goes over the drawing window's right edge, or the tooltip's bottom edge goes over the drawing window's bottom edge. In those two situations traces of the tooltip get left behind on the image canvas until the display is refreshed manually (desktop switch, dragging another window in front etc.). No problems at the top or left boundaries though, just right / bottom.
Pop-up menus behave in exactly the same way as tooltips; they get cleared OK if they're wholly within the image canvas (or overlapping top / left edges), but don't force a redraw when they're overlapping right / bottom margins of the image canvas window.
The image canvas now correctly redraws itself when other X or Wine windows obscure it and then move away, or I switch desktops etc.
I've seen one total application lockup when moving another X window across the front of the PSP ones managed by Wine, but I need to do some more investigation there to try and figure out what symptoms cause it though.
Still, looking good on the whole, so a big thanks to whoever's been messing with the redraw code lately! (Vitaly?)
cheers
Jules
-- Regards Signer: Eddy Nigg Company: StartCom Linux at www.startcom.org <http://www.startcom.org/> MediaHost^(TM) at www.mediahost.org <http://www.mediahost.org/> Skype: startcom <callto://startcom/> Phone: +1.213.341.0390 Import StartCom Public CA <http://cert.startcom.org/index.php?app=109>
participants (5)
-
Jules Richardson -
Marcus Meissner -
MediaHost (TM) -
Vitaliy Margolen -
wino＠piments.com