1. w32lib error?

I was getting a divide by zero error from Win32Lib.ew, so I modified it in routine createPixmap() to put in the code marked below by ===> (obviously, the "===>" is not in the code when I am running it, this is just to highlight it here) in an effort to debug it:

===>  atom result 
 
        -- get the dc of the screen 
        hdc = getDC( Screen ) 
 
        -- create a window sized bitmap compatible with the screen 
===>  result = message_box ( sprintf("pWidth = %d, pHeight = %d", { pWidth, pHeight }), "createPixmap", 0) 
   
        handle = w32Func( xCreateCompatibleBitmap, { hdc, pWidth, pHeight } ) 
        -- release the dc 
        releaseDC( Screen ) 
 
        if handle = NULL then 
            warnErr( Err_CREATEPIXMAP ) 
        end if 

This showed me that the value used for pWidth is 26833 and for pHeight is 3556. This is consistent with what my own code told me it was passing to setRect() which then calls setCtlSize() which in turn calls createPixmap(). The program then dies with a divide by zero error as shown in this bit of the DOS window from it dying:

c:\euphoria-40b2\win32lib\include\w32msgs.e:113 in procedure fShowError() attempt to divide by 0

... called from c:\euphoria-40b2\win32lib\include\Win32Lib.ew:12885 in procedure createPixmap()

... called from c:\euphoria-40b2\win32lib\include\Win32Lib.ew:19539 in procedure setCtlSize()

... called from c:\euphoria-40b2\win32lib\include\Win32Lib.ew:19611 in procedure setRect()

Line 12885 as referenced is the call to the warnErr() routine shown in the code snippet above.

This code works until I try to use it with these large values, but this was working for the last several days, even on this large virtual window. The call to Win32Lib.ew which failed here is no different than it has been for the last few days.

Any ideas what is wrong here? Could my Vista box just be in need of rebooting? It looks like this is in the Windows function code that the divide is happening.

Thanks for any suggestions.

new topic     » topic index » view message » categorize

2. Re: w32lib error?

JoKeR said...

This showed me that the value used for pWidth is 26833 and for pHeight is 3556. This is consistent with what my own code told me it was passing to setRect() which then calls setCtlSize() which in turn calls createPixmap(). The program then dies with a divide by zero error as shown in this bit of the DOS window from it dying:

This code works until I try to use it with these large values, but this was working for the last several days, even on this large virtual window. The call to Win32Lib.ew which failed here is no different than it has been for the last few days.

Any ideas what is wrong here? Could my Vista box just be in need of rebooting? It looks like this is in the Windows function code that the divide is happening.

I'm not sure which version of win32lib you're using, but looking at createPixmap(), I find one call to warnErr():

        -- create a window sized bitmap compatible with the screen 
        handle = w32Func( xCreateCompatibleBitmap, { hdc, pWidth, pHeight } ) 
        -- release the dc 
        releaseDC( Screen ) 
 
        if handle = NULL then 
            warnErr( Err_CREATEPIXMAP ) 
        end if 
 

So it looks like windows didn't/couldn't create your pixmap. Those large values are pretty huge. I'm not sure what the maximum size for a pixmap is (or exactly how it's stored) but just multiplying width by height is over 95 million. You'd need to multiply by 8 or 16 or more, depending on the color depth, I'd guess (I'm assuming that pixmaps don't compress in memory, which seems like a pretty safe bet).

So you're talking hundreds of MBs to GBs, purely for memory to store the pixels. I suspect that you need contiguous memory in order to do that. There might not be enough contiguous blocks of RAM to do this. Or you could be hitting other constraints set by windows. You might try experimenting to see what the limits are.

Matt

new topic     » goto parent     » topic index » view message » categorize

3. Re: w32lib error?

I like your idea about the memory fragmentation leaving not enough room. I realize this is a huge graphic image I'm building in memory, but I'm playing with a game program which uses part of the screen as a portal into a small portion of that image and can then scroll around the image using scroll bars. I deliberately tried something this large just to see if I ran into any issues with it. Apparently I have.

I have rebooted my computer and I can now run that program with that same huge graphic image without problems.

Thanks for the prompt response.

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu