John Labenski <jlaben...@gmail.com> wrote: (04/03/2009 07:08) >-- YOU MUST DELETE THE PEN and COLOUR! > local c = wx.wxColour(255,0,0) > local p = wx.wxPen(c,1,wx.wxSOLID) >> DC:SetPen(p) > p:delete() > c:delete() >> DC:DrawLine(0,0,600,600) >> DC:delete() >> end
Good, that is exactly what I had in mind, and is why I asked. The way I had it appears lots of times found via Google but I asked because I didn't trust it. >> Why does it need s status bar? It still borks and displays nothing without >> that being there, and I still can't see why.. > >Move FRAME:Show(true) to the end of the main() function, this forces a >refresh and everything will be laid out by then. > I want to show the frame first, so something can be seen (frame, messages during data load), so maybe force frame refresh directly? I tried FRAME:Refresh() at the end of Main() but that didn't work. I'll want a status bar anyway, but solving this would let me choose some other time. >> Is there a way to make the BITMAP draw once and still work, so I can delete >> it once it's drawn to the DC for the CHART panel? Is this even in line with >> the advice on deleting large bitmaps to save resources in MSW? > >No, you have to repaint it every time a wxPaintEvent is sent. This is >normal for GUI programs and even if somebody else drew it for you it'd >still have to store the bitmap. Ok, I realised that soon after writing, it has to be there so any motion of the image has a source to redraw from too. >You should also add a wx.wxEVT_ERASE_BACKGROUND handler that does >nothing, the same as event:Skip(false), to reduce flicker. > Already done, that was first thing after posting once I saw the flicker, I'd already found descriptions of ways to reduce it. >> And, why DC:delete() not DC:Delete() like XYZ:Refresh() or ABC:Show()...? :) >> Small case-sensitive gotchas like this are one thing that really makes it >> tough to debug stuff for newcomers. > >"delete" is a reserved word in C++ so it cannot be a function name. >Therefore, wxLua can add it as a function to the userdata without any >worries that we will hide any existing functions. > Ok. >> If the code is now correct, I want to focus on scaling, so should I do this >> by converting the loaded bitmap to a wxImage() or would it be faster just to >> load prescaled bitmaps? If the former, can you give me a minimal template >> for building the needed conversions into the current code? I can convert to >> image but I'm not clear at what point the image should be deleted after >> reconversion to bitmap, or even how to reconvert it. > >I would load the original as a wxImage and convert it to a wxBitmap >for drawing, saving both of these. If the zoom changes, use the >wxImage functions to rescale into the same wxBimap and use this to >draw into your DC. That way your wxBitmap is ready to go when it comes >time to paint. If you plan to zoom way in or the image is huge you may >want to crop the wxImage to a temporary wxImage of the size and >position of the scrolled window before scaling it, then create the >wxBitmap for drawing, but note that you will have to do this in real >time for scrolling. > >> You mentioned cropping. This sounds good if it allows a speed gain by >> avoiding having to draw the whole of a large image. Will it do that though? >> I imagine that the dragging of the image will cause this image crop and >> display to occur with every pixel-shift of motion, and not be fast at all. > >I have had success with doing what I mentioned above, it has been fast enough. > >Hope this helps, > John > Nice, I'll try it. It's close to what I had in mind too.The bit about 'saving' both the wxImage and wxBitmap puzzles me though, you mean to file on disk, or to a holding variable at runtime? (I guess latter). Also, if I opt for a crude pixel resize, is there a way that doesn't need to use the wxImage? (Pixel resize is fast, and adequate for this, probably.) I'll still likely use the wxImage though, because the image IS huge, I'll definitely want to crop it if it works fast. (1.2 GHz ITX board, running W98 SE). I've worked out the scaling from fix data to map and shown an accurate overlay, and my next step will be to do colour coding for the track to indicate speed. Gradients based on the resistor colour code. :) This is ok from 0 to 9 miles per hour, but I'll have to think about what to do from 10 to 19, etc... Thicker lines, maybe different styles if they show up ok. I'll view more data that way than by scaling the image so I'll go with that first. For neat panning of a large or zoomed image using cropped sub-sections, it could get complex, like the Google maps method of loading unseen tiles in advance beyond the viewable area. I won't take that on unless it looks like I'll need to. I might just allow a way to point at something and request a momentary zoom of a preset area centred on said point. Much simpler, and more immediate. ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ wxlua-users mailing list wxlua-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxlua-users
