wxlua-users Mailing List for wxLua

John Labenski <jla...@gm...> 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.

John Labenski <jla...@gm...> wrote:
(04/03/2009 07:14)

>
>On Sat, Feb 28, 2009 at 4:00 PM, lostgallifreyan
><los...@gm...> wrote:
>>
>> There's definitely something wrong though, if you run this and drag a lot of files, some bizarrely large co-ordinates are reported, and sometimes it will even crash wxLua (Shell32.dll in W98 SE running W95 shell, (W98-Lite)). I can repeat the errors but I have no idea what it is about the file names or file counts, or positions on screen, or anything else that might be causing the trouble. It seems to work fine for up to ten files or so.
>
>I can't reproduce this. I can drop 975 files repeatedly without any problems.
>
>Regards,
>    John
>

No strangely large values for the drop position? I often see them, with large file counts. 10137 seems to be constant for X when it happens, the Y value is variable but is huge, 13nnnnnn, with first n usually 6, sometimes 7. No idea what it means though. I managed to crash it with several thousand files, this time with User.exe.

WXLUA caused a general protection fault
in module USER.EXE at 0004:00005ff0.
Registers:
EAX=5002fffc CS=17a7 EIP=00005ff0 EFLGS=00000e16
EBX=00008070 SS=4b9f ESP=0000806c EBP=00008088
ECX=00007fd7 DS=66d7 ESI=0002ffac FS=0000
EDX=8df216b7 ES=1d57 EDI=0000fffe GS=0000
Bytes at CS:EIP:
f3 a5 73 03 46 47 a4 fc eb 08 fc d1 e9 f3 a5 73 
Stack dump:
00520043 17b707bc 0052fffe 00001d57 000066d7 001d0030 00001d57 0eee8100 fffe0082 66d70000 00e55348 003a000b 50022080 0043ffff 816c1d57 539f8132 

I don't know if those messages have any use for you but it's here in case it does. That was from a drop of 3608 files. Pointless really, but when it happens with a drop of around thirty it is more interesting. It seemed to matter which thirty or so, but the patterns made by the possible selections, plus the specific conditions of my OS, make it highly unlikely that any useful consistency can be found, except the unusual values of those X and Y co-ordinates, maybe.

On Sat, Feb 28, 2009 at 4:00 PM, lostgallifreyan
<los...@gm...> wrote:
>
> There's definitely something wrong though, if you run this and drag a lot of files, some bizarrely large co-ordinates are reported, and sometimes it will even crash wxLua (Shell32.dll in W98 SE running W95 shell, (W98-Lite)). I can repeat the errors but I have no idea what it is about the file names or file counts, or positions on screen, or anything else that might be causing the trouble. It seems to work fine for up to ten files or so.

I can't reproduce this. I can drop 975 files repeatedly without any problems.

Regards,
    John

On Sun, Mar 1, 2009 at 3:22 PM, lostgallifreyan
<los...@gm...> wrote:
>
> First, the code, in FULL because the one thing that made my day most difficult is snippets out of context. So much easier if a copy/paste of a working example can be had, then debugging is simple, focus on what change breaks something. For small examples I see no better way than this..
>
> function main()
>  FRAME=wx.wxFrame(wx.NULL,-1,"GPS Plot",wx.wxDefaultPosition,wx.wxSize(1024,768),wx.wxDEFAULT_FRAME_STYLE)
>  FRAME:Centre()  FRAME:Show(true)
>  FRAME:CreateStatusBar()
>
>  BITMAP=wx.wxBitmap("../Charts/Ashton Court.gif",wx.wxBITMAP_TYPE_GIF)
>  local X,Y=BITMAP:GetWidth(),BITMAP:GetHeight()
>  SCROLL=wx.wxScrolledWindow(FRAME,-1)  SCROLL:SetScrollbars(1,1,X,Y)
>  CHART=wx.wxPanel(SCROLL,-1,wx.wxPoint(0,0),wx.wxSize(X,Y))
>
>  CHART:Connect(wx.wxEVT_LEFT_DOWN,OnLeftDown)
>  CHART:Connect(wx.wxEVT_MOTION,OnMotion)
>  CHART:Connect(wx.wxEVT_PAINT,OnPaint)
> end
>
> --====================  Mouse Handling  ====================--
>
> MX,MY,VX,VY=0,0,0,0
>
> function OnLeftDown(event)
>  MX,MY,VX,VY=wx.wxGetMousePosition():GetX(),wx.wxGetMousePosition():GetY(),SCROLL:GetViewStart()
> end
>
> function OnMotion(event)
>  if event:LeftIsDown() then
>    SCROLL:Scroll(VX+MX-wx.wxGetMousePosition():GetX(),VY+MY-wx.wxGetMousePosition():GetY())
>  end
> end
>
> --====================  Track Drawing  =====================--
>
> function OnPaint(event)
>  local DC=wx.wxPaintDC(CHART)
>  DC:DrawBitmap(BITMAP,0,0,false)

-- 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
>
> --==========================================================--
>
> main()
>
>
>
> The questions:
> 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.

> 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.

You should also add a wx.wxEVT_ERASE_BACKGROUND handler that does
nothing, the same as event:Skip(false), to reduce flicker.

> Is it wise to expand the OnPaint() function to assign the wxPen and wxColour to variables on creation so I can delete them individually? I'm not clear as to whether they are orphaned and consuming resources after the DC:delete(). I do suspect that something persists, as after a few tens of loads in a session, the script was failing to draw the chart, only the line.

You MUST always delete these, see above and the docs,
http://wxlua.sourceforge.net/docs/wxlua.html, and search for "Must
delete".

> 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.

> 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