John Labenski <jlaben...@gmail.com> wrote: (15/05/2009 17:11) >On Fri, May 15, 2009 at 7:21 AM, lostgallifreyan ><lostgallifre...@gmail.com>wrote: >
>Connect to the wxEVT_ERASE_BACKGROUND event and call event:Skip(false) to >block erasing the background if you use a wxEVT_PAINT handler. > I already know that one, I use it to solve edge flickers when moving the chart. It doesn't help though. I posted the whole code in that previous mail so you could see why. (Since further reduced variable count and improved speed, but what I posted works right). That mail shows how I used the DrawBitmap X,Y values directly. I can't avoid flicker between the OnPainted chart and the overlay because to work that way MUST redraw both chart and layer, or nothing is going to move. :) I since used the StaticBitmap and CHART:Move(LX,LY) to make the moves, so I don't have to refresh the StaticBitmap. That way, wxEVT_ERASE_BACKGROUND actually helps as advertised, and I get a way to reduce the vector draw count with each move.. I won't post it yet, not till it's cleaner and does significantly better than the last one I sent. > >> >> All that is made possible with the way wxStaticBitmap() works. So if I >> shouldn't use it and have to make my own control to emulate its useful >> behaviour but for images thousands of pixels wide, what should I do? The >> wxWidgets manual doen't have any suggestions for this. >> > >If it works then that's fine. I just remember that at one point the >wxStaticBitmap had problems with large images, but this may be fixed now. > Ok. Looks good to me anyway. I read that on Windows it's said to be limited in size (very small, around 64 px per side!) and be limited also in use of palette. I'm using W98 SE and have seen no such restrictions. It actually works better than using a standard DC to draw to a panel on a ScrolledWindow, which I abandoned since the mouse tracking had tiny lags that showed in jittery updates of position. The direct paint co-ordinates, or Window:Move() methods are faster and seem to be more efficient. One thing I did was revert to the wx.wxGetMousePosition():GetX(). While event:GetX() looks neater it's not much fun trying to get position from the object you're also trying to move... I'd tried a third panel purely as a mouse input control layer, but it was an ugly fix compared to reverting to full screen co-ords, as I only need relative shifts anyway, and calculated them as part of the code in either system. ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ wxlua-users mailing list wxlua-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxlua-users
