On 28.01.12 19:54, Le_Forgeron wrote:
>> I have not run an animation this large in Windows, so I don't know if it's a
>> >  problem there.
> Well, if someone can try that on Windows (animation, picture size bigger
> in any dimensions, including both, than the available display)
>

Why would a crash in Unix-specific code have any impact on Windows-specific 
code?

     Thorsten

Post a reply to this message

On 01/28/2012 04:03 PM, Chris Cason wrote:
> On 29/01/2012 08:00, Jim Holsenback wrote:
>>> hmmm ... ~smp/unix/disp_sdl.cpp shows no difference with the version I
>>> have locally, so I couldn't do a diff to see what you'd changed. Wanted
>>> to pull the fix and do a little sanity check, but was unable to proceed.
>>
>> BTW: I have version #19 of the above mentioned file.
>
> It probably needs to be merged to trunk. I'll take a look at it later
> today.
>
> -- Chris

operator error I guess ... my p4 client hung and it must have pulled the 
file anyways, because when I came back at it ... said no files updated. 
After some more digging version #19 is indeed what I want and have.

Post a reply to this message

Le 28/01/2012 22:09, Thorsten Froehlich nous fit lire :
> On 28.01.12 19:54, Le_Forgeron wrote:
>>> I have not run an animation this large in Windows, so I don't know if
>>> it's a
>>> >  problem there.
>> Well, if someone can try that on Windows (animation, picture size bigger
>> in any dimensions, including both, than the available display)
>>
> 
> Why would a crash in Unix-specific code have any impact on
> Windows-specific code?

Not directly, but a similar error might have been copied&pasted... or
served as a common design (by same authors or like, so it was an error
on unix, it might also on others.. I just do not know their ways of
handling the scaling (if any) of large pictures)

Better check while at it than sorry in 8 months.

Post a reply to this message

On 29.01.12 12:11, Le_Forgeron wrote:
> Le 28/01/2012 22:09, Thorsten Froehlich nous fit lire :
>> On 28.01.12 19:54, Le_Forgeron wrote:
>>>> I have not run an animation this large in Windows, so I don't know if
>>>> it's a
>>>>>   problem there.
>>> Well, if someone can try that on Windows (animation, picture size bigger
>>> in any dimensions, including both, than the available display)
>>>
>>
>> Why would a crash in Unix-specific code have any impact on
>> Windows-specific code?
>
> Not directly, but a similar error might have been copied&pasted... or
> served as a common design (by same authors or like, so it was an error
> on unix, it might also on others.. I just do not know their ways of
> handling the scaling (if any) of large pictures)

Well, xcb_io.c is a system library and not POV-specific, so it cannot be a 
POV-Raz bug. Googling suggests the assertion failure is actually a race 
condition in some ATI binary-only graphics drivers...

	Thorsten

Post a reply to this message

Le 2012/01/29 06:11, Le_Forgeron a écrit :
> Le 28/01/2012 22:09, Thorsten Froehlich nous fit lire :
>> On 28.01.12 19:54, Le_Forgeron wrote:
>>>> I have not run an animation this large in Windows, so I don't know if
>>>> it's a
>>>>>   problem there.
>>> Well, if someone can try that on Windows (animation, picture size bigger
>>> in any dimensions, including both, than the available display)
>>>
>>
>> Why would a crash in Unix-specific code have any impact on
>> Windows-specific code?
>
> Not directly, but a similar error might have been copied&pasted... or
> served as a common design (by same authors or like, so it was an error
> on unix, it might also on others.. I just do not know their ways of
> handling the scaling (if any) of large pictures)
>
> Better check while at it than sorry in 8 months.

Using the Windows version, if the image is larger than the display, the 
image is not scaled but scroll bars will appears.
If you maximize the display window, then the image is scaled.
Tested at 3200 by 1200 (1600 by 1200 display) and got no problem when 
starting the second frame with display maximized.


Alain

Post a reply to this message

On 01/29/2012 03:53 PM, Thorsten Froehlich wrote:
> On 29.01.12 12:11, Le_Forgeron wrote:
>> Le 28/01/2012 22:09, Thorsten Froehlich nous fit lire :
>>> On 28.01.12 19:54, Le_Forgeron wrote:
>>>>> I have not run an animation this large in Windows, so I don't know if
>>>>> it's a
>>>>>> problem there.
>>>> Well, if someone can try that on Windows (animation, picture size
>>>> bigger
>>>> in any dimensions, including both, than the available display)
>>>>
>>>
>>> Why would a crash in Unix-specific code have any impact on
>>> Windows-specific code?
>>
>> Not directly, but a similar error might have been copied&pasted... or
>> served as a common design (by same authors or like, so it was an error
>> on unix, it might also on others.. I just do not know their ways of
>> handling the scaling (if any) of large pictures)
>
> Well, xcb_io.c is a system library and not POV-specific, so it cannot be
> a POV-Raz bug. Googling suggests the assertion failure is actually a
> race condition in some ATI binary-only graphics drivers...
>
> Thorsten

Last month I abandoned my upgrade to opensuse12.1 (same as original 
poster) because of a problem I was seeing with the ATI drivers. I didn't 
get to do a postmortem on the upgrade to figure out what happened, I 
just went back to 11.2 instead ... When I saw the initial post I 
couldn't remember why xcb_io.c looked awful familiar. Thanks for the 
nudge ;-)

Post a reply to this message

Le 29/01/2012 21:53, Thorsten Froehlich a écrit :
> On 29.01.12 12:11, Le_Forgeron wrote:
>> Le 28/01/2012 22:09, Thorsten Froehlich nous fit lire :
>>> Why would a crash in Unix-specific code have any impact on
>>> Windows-specific code?
>>
>> Not directly, but a similar error might have been copied&pasted... or
>> served as a common design (by same authors or like, so it was an error
>> on unix, it might also on others.. I just do not know their ways of
>> handling the scaling (if any) of large pictures)
> 
> Well, xcb_io.c is a system library and not POV-specific, so it cannot be
> a POV-Raz bug. Googling suggests the assertion failure is actually a
> race condition in some ATI binary-only graphics drivers...

I was talking about the missing .reserve() (and the loop of
initialisation) of m_PxCount in TakeOver (when the crash happened on the
second frame, it's because m_PxCount is indeed an empty vector, so it
does not like Povray accessing any of its element).

Ambiguous quote from previous messages are my fault, all my fault, all
my big fault.

Alain did check the windows port, seems fine. That's a good news.

what about the Mac port ? (or is it unix based now ?)


The xcb_io.c issue is yet another issue, but I cannot reproduce it (I'm
on Ubuntu with a nvidia card). I could use a VirtualMachine (VM) to get
an OpenSuse, but that won't create any Ati card.

Post a reply to this message

On 01/30/2012 08:07 AM, Le_Forgeron wrote:
> The xcb_io.c issue is yet another issue, but I cannot reproduce it (I'm
> on Ubuntu with a nvidia card). I could use a VirtualMachine (VM) to get
> an OpenSuse, but that won't create any Ati card.

no promises ... but I'll try to massage my opensuse12.1 upgrade in the 
proper direction this week, perhaps with some luck ATI driver issues 
have been resolved and they'll have a new download

Post a reply to this message

Jim Holsenback <nom### [at] nomailcom> wrote:
> no promises ... but I'll try to massage my opensuse12.1 upgrade in the 
> proper direction this week, perhaps with some luck ATI driver issues 
> have been resolved and they'll have a new download

  If the ATI linux drivers are causing you problems, try using an older
version of the drivers. In my box 10-8 works ok.

  (Remember that you need to run aticonfig after installing a driver
which version deviates significantly from what you currently have.
I have noticed that the xorg.xonf files they generate are not always
compatible.)

-- 
                                                          - Warp

Post a reply to this message

On 01/31/2012 11:33 AM, Warp wrote:
> Jim Holsenback<nom### [at] nomailcom>  wrote:
>> no promises ... but I'll try to massage my opensuse12.1 upgrade in the
>> proper direction this week, perhaps with some luck ATI driver issues
>> have been resolved and they'll have a new download
>
>    If the ATI linux drivers are causing you problems, try using an older
> version of the drivers. In my box 10-8 works ok.
>
>    (Remember that you need to run aticonfig after installing a driver
> which version deviates significantly from what you currently have.
> I have noticed that the xorg.xonf files they generate are not always
> compatible.)
>

yep ... found that the Modules section in xorg.conf was empty. I'm good 
to go now, and have latest drivers from geeko repository and all appears 
fine ... now let's see if I can do a povray build ;-)

Post a reply to this message