I'm feeling narcolepsy coming on (although my ability to sleep is likely to be
compromised by this stupid rash, which has become itchy :-( )...
So I think I'm done for this release. Besides, Brian's been waiting more than
patiently for me to finish...
What's done:
- Blockbuster can be invoked without arguments; the GTK interface will ask for a
movie to open.
- Up to four recent movies (opened with any interface) will be presented as
quick options in the Open dialog box.
- There's a zoom control; I tried a slider, but a spin box turned out to be
easier to use.
- Warnings and errors will appear in dialog boxes. (Other messages will still
go to console.)
- Current frame size in pixels is reported
What's not done:
- Long arguments for options (e.g. "-display" instead of "-d")
- Play behaviors (Stop at End, Loop, Swing)
- Selectable start and end frames
- Pretty graphics on the buttons
- Manual setting of Pan parameters
- Scripting
- Fixing the 3 bugs that are sure to be present ;-)
All of these are pretty simple to implement (well, except maybe for the last two
;-).
papillo the pruritic

Holger Jones wrote:
>>- We don't support all the functionality of xmovie, in particular:
>> - Play->Stop at End
>> - Play->Swing
>> - Edit->Limits (start and stop frames)
>> - Edit->Pan-Zoom (manually set pan and zoom)
>>Are any of these required?
>>
>>So, I'm planning on implementing the first three, but not the last two at this
>>juncture. Speak now or forever hold your peace... :-)
>>
>>papillo the morbid
>>Bob Ellison, Tungsten Graphics, Inc.
>>
>>
>>
>>
> I think we can use all of them as play, loop, stop at end, edit
> limits and edit pan-zoom are probably most useful when running
> blockbuster under script control. For user interaction, edit limits
> is the most useful thing to add for now.
Those options weren't listed in the specification so if Bob can't get
them done in time for the release later today, we could probably tack
them on next week.
>>Try this patch to smBase.C:
>>
>>
>>diff -r1.10 smBase.C
>>1271c1271
>>< if (curwin[winnum] != f) {
>>---
>> > if (1 /** curwin[winnum] != f **/) {
>>1282c1282
>>< fprintf(stderr,"done waiting for winnum %d f %d\n",winnum,f);
>>---
>> > // fprintf(stderr,"done waiting for winnum %d f
>>%d\n",winnum,f);
>>1284c1284
>>< if (curwin[winnum] != f) {
>>---
>> > if (1 /** curwin[winnum] != f **/) {
>>
>>
>>I keep forgetting to send this to you, Holger. Without it, I get
>>corruption too.
>>
>>-Brian
>>
>>
>>
> This one has me puzzled as the lockFrame prototype you've modified
> should only kick in for version 1 movies or movies with no tiling. So
> for backward compatibility sake I have left the original lockFrame
> alone. The code that calls lockFrame
>
>
> if((version == 2) && (numTiles > 1)) {
> cdata = (u_char *)lockFrame((int)_f, size,
> &_dim[0],&_pos[0],(int)_res);
> int winnum = _f % nwin;
>
> //fprintf(stderr,"winnum %d\n",winnum);
>
> tbuf = (u_char *)tile_buf[winnum];
> tinfo = (tileOverlapInfo_t *)tile_info[winnum];
> }
> else {
> cdata = (u_char *)lockFrame(_f, size); <------------------ are
> we landing here ???
> }
>
>
> Brian and Bob -- could you elaborate on when the corruption is
> triggered.
Hmmm, I undid my changes to smBase.C (seen above) and I don't see any
corruption now. Strange. Everything seems fine. I guess I'll back
out my check-in to smBase.C and see what happens.
> Did you see this prior to the openFile functionality. What
> does sminfo report for your file(s) under test. Maybe the initial res
> value is not being reset for the new movie as this may cause a numTiles
> error. Anyhow, for test purposes I'll put an assert to always fail if I
> call the older lockFrame and see what happens. I admit to not seeing
> this problem with my files -- so this will be priority for me until this
> is solved.
>
> Could you give me a lockFrame trace (version 1 or version 2 printfs
> during the run) if this is easily repeatable.
If I see the corruption again, I'll dig deeper.
-Brian

blockbuster-devel-request@... wrote:
>Send Blockbuster-devel mailing list submissions to
> blockbuster-devel@...
>
>To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/blockbuster-devel
>or, via email, send a message with subject or body 'help' to
> blockbuster-devel-request@...
>
>You can reach the person managing the list at
> blockbuster-devel-admin@...
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Blockbuster-devel digest..."
>
>
>Today's Topics:
>
> 1. What's left? (Robert Ellison)
> 2. Re: What's left? (Brian Paul)
> 3. Re: What's left? (Brian Paul)
> 4. Re: What's left? (Robert Ellison)
> 5. Re: What's left? (Brian Paul)
> 6. Re: What's left? (Brian Paul)
> 7. SM/LOD file read problem? (Robert Ellison)
> 8. Re: SM/LOD file read problem? (Brian Paul)
>
>--__--__--
>
>Message: 1
>Date: Thu, 28 Aug 2003 04:37:12 -0600
>From: Robert Ellison <papillo@...>
>Organization: Tungsten Graphics
>To: blockbuster-devel@...
>Subject: [Blockbuster-devel] What's left?
>
>After a spiffy new splash screen (the old one looked terrible if it popped up on
>a white background) and a bunch of new GTK interface functionality, I'm inclined
>to ask what else should be done before the end of month.
>
>- One thing comes to mind: although the Open... box works, it doesn't yet have
>an option to easily open the last few movies. I'm planning on doing this in
>between West Nile-induced bouts of fatigue on Thursday (I guess that's today,
>for those of you who aren't awake yet ;-).
>
>- As a related issue, blockbuster currently exits if opened without a named
>movie; it seems like it would be nicer with the GTK interface if blockbuster
>came up with an "Open File..." dialog box if no movie were named. I'm planning
>on this as well.
>
>- As a user interface issue, I plan to have warnings and errors reported through
>the GTK user interface instead of to the console (I'd implemented this once
>before, but lost the changes before I checked them in).
>
>- We don't support SGI RGB; this was listed in the original spec, but we never
>confirmed it was needed (at least, as far as I'm aware, no one responded to my
>mail of 4 August asking if that format were needed).
>
>- We don't support all the functionality of xmovie, in particular:
> - Play->Stop at End
> - Play->Swing
> - Edit->Limits (start and stop frames)
> - Edit->Pan-Zoom (manually set pan and zoom)
>Are any of these required?
>
>So, I'm planning on implementing the first three, but not the last two at this
>juncture. Speak now or forever hold your peace... :-)
>
>papillo the morbid
>Bob Ellison, Tungsten Graphics, Inc.
>
>
>
>
I think we can use all of them as play, loop, stop at end, edit limits
and edit pan-zoom are probably most useful when running blockbuster
under script control. For user interaction, edit limits is the most
useful thing to add for now.
>--__--__--
>
>Message: 2
>Date: Thu, 28 Aug 2003 09:43:08 -0600
>From: Brian Paul <brian@...>
>Organization: Tungsten Graphics, Inc.
>To: Robert Ellison <papillo@...>
>CC: blockbuster-devel@...
>Subject: Re: [Blockbuster-devel] What's left?
>
>Robert Ellison wrote:
>
>
>>After a spiffy new splash screen (the old one looked terrible if it
>>popped up on a white background) and a bunch of new GTK interface
>>functionality, I'm inclined to ask what else should be done before the
>>end of month.
>>
>>- One thing comes to mind: although the Open... box works, it doesn't
>>yet have an option to easily open the last few movies. I'm planning on
>>doing this in between West Nile-induced bouts of fatigue on Thursday (I
>>guess that's today, for those of you who aren't awake yet ;-).
>>
>>- As a related issue, blockbuster currently exits if opened without a
>>named movie; it seems like it would be nicer with the GTK interface if
>>blockbuster came up with an "Open File..." dialog box if no movie were
>>named. I'm planning on this as well.
>>
>>- As a user interface issue, I plan to have warnings and errors reported
>>through the GTK user interface instead of to the console (I'd
>>implemented this once before, but lost the changes before I checked them
>>in).
>>
>>- We don't support SGI RGB; this was listed in the original spec, but we
>>never confirmed it was needed (at least, as far as I'm aware, no one
>>responded to my mail of 4 August asking if that format were needed).
>>
>>- We don't support all the functionality of xmovie, in particular:
>> - Play->Stop at End
>> - Play->Swing
>> - Edit->Limits (start and stop frames)
>> - Edit->Pan-Zoom (manually set pan and zoom)
>>Are any of these required?
>>
>>So, I'm planning on implementing the first three, but not the last two
>>at this juncture. Speak now or forever hold your peace... :-)
>>
>>
>
>After reviewing things:
>
>1. I think we're supposed to display the current movie size (width x
>height) somewhere.
>
>2. The level of detail control in the GUI doesn't work properly. It
>seems to fight going to level 0 when using the 4kx4k test file.
>
>3. The original spec calls for a slider to control zoom.
>
>4. The spec calls for RGB file support. I can do that since I've got
>code for it lying around.
>
>-Brian
>
>
>
>--__--__--
>
>Message: 3
>Date: Thu, 28 Aug 2003 11:22:20 -0600
>From: Brian Paul <brian@...>
>Organization: Tungsten Graphics, Inc.
>To: blockbuster-devel@...
>CC: Robert Ellison <papillo@...>
>Subject: Re: [Blockbuster-devel] What's left?
>
>Brian Paul wrote:
>
>
>>Robert Ellison wrote:
>>
>>
>>
>>>After a spiffy new splash screen (the old one looked terrible if it
>>>popped up on a white background) and a bunch of new GTK interface
>>>functionality, I'm inclined to ask what else should be done before the
>>>end of month.
>>>
>>>- One thing comes to mind: although the Open... box works, it doesn't
>>>yet have an option to easily open the last few movies. I'm planning
>>>on doing this in between West Nile-induced bouts of fatigue on
>>>Thursday (I guess that's today, for those of you who aren't awake yet
>>>;-).
>>>
>>>- As a related issue, blockbuster currently exits if opened without a
>>>named movie; it seems like it would be nicer with the GTK interface if
>>>blockbuster came up with an "Open File..." dialog box if no movie were
>>>named. I'm planning on this as well.
>>>
>>>- As a user interface issue, I plan to have warnings and errors
>>>reported through the GTK user interface instead of to the console (I'd
>>>implemented this once before, but lost the changes before I checked
>>>them in).
>>>
>>>- We don't support SGI RGB; this was listed in the original spec, but
>>>we never confirmed it was needed (at least, as far as I'm aware, no
>>>one responded to my mail of 4 August asking if that format were needed).
>>>
>>>- We don't support all the functionality of xmovie, in particular:
>>> - Play->Stop at End
>>> - Play->Swing
>>> - Edit->Limits (start and stop frames)
>>> - Edit->Pan-Zoom (manually set pan and zoom)
>>>Are any of these required?
>>>
>>>So, I'm planning on implementing the first three, but not the last two
>>>at this juncture. Speak now or forever hold your peace... :-)
>>>
>>>
>>After reviewing things:
>>
>>1. I think we're supposed to display the current movie size (width x
>>height) somewhere.
>>
>>2. The level of detail control in the GUI doesn't work properly. It
>>seems to fight going to level 0 when using the 4kx4k test file.
>>
>>3. The original spec calls for a slider to control zoom.
>>
>>4. The spec calls for RGB file support. I can do that since I've got
>>code for it lying around.
>>
>>
>
>A few more items:
>
>5. The frame rate slider should go to 100 at least, or have an
>infinity option. Perhaps a spinbox would be better. Another problem
>with the slider is that it's hard to make 1 fps increments/decrements
>since it's so short.
>
>6. We should compute do a zoom-to-fit upon first loading a movie.
>
>7. Do we want to have the LOD automatically reduced when we can't meet
>the desired frame rate? That could be a bit tricky.
>
>-Brian
>
>
>
>--__--__--
>
>Message: 4
>Date: Thu, 28 Aug 2003 11:59:03 -0600
>From: Robert Ellison <papillo@...>
>Organization: Tungsten Graphics
>To: Brian Paul <brian@...>
>CC: blockbuster-devel@...
>Subject: Re: [Blockbuster-devel] What's left?
>
>
>
>>>1. I think we're supposed to display the current movie size (width x
>>>height) somewhere.
>>>
>>>
>
>A fifth status line? (Which size - original size? Region of interest in
>pixels? Region of interest in zoomed pixels?)
>
>
>
>>>2. The level of detail control in the GUI doesn't work properly. It
>>>seems to fight going to level 0 when using the 4kx4k test file.
>>>
>>>
>
>?
>
>I'm not sure I'm seeing this (well, since I'm using the same file, I must be
>seeing it, but may be interpreting it incorrectly).
>
>If the GUI sends back a level of detail that the application refuses to
>acknowledge (likely if the level gets clamped), the application will tell the
>GUI to update its level of detail value to the value being used.
>
>Depending on the situation, this could appear to be a "fight".
>
>The correct answer is to dynamically update the range of the LOD slider based on
>the current zoom and the available levels. (Brian, I'll try to figure out the
>math after handling a few other things; if you get to it before I do, the UI
>call is ReportRateRangeChange(), which must be checked to be non-NULL before
>executing.)
>
>
>
>>>3. The original spec calls for a slider to control zoom.
>>>
>>>
>
>Is such still wanted? We're at the point where the toolbox is becoming bigger,
>and I'm not sure the extra tool is useful (given that mouse button 2 performs
>the same function).
>
>I know it's in the spec; we're just far enough out of spec already (supporting
>multiple renderers & user interfaces, for example, when only one was desired)
>and close enough to final release that I'd like to be sure it's still wanted.
>
>But hey, it's easy enough to remove the tool if you don't want it, I suppose.
>
>
>
>>5. The frame rate slider should go to 100 at least, or have an infinity
>>option. Perhaps a spinbox would be better. Another problem with the
>>slider is that it's hard to make 1 fps increments/decrements since it's
>>so short.
>>
>>
>
>Spin box is fine with me. Maybe I'll put it in the same box with the detail
>spinbox (saving real estate).
>
>
>
>>6. We should compute do a zoom-to-fit upon first loading a movie.
>>
>>
>
>When loading a new movie, yes? In most cases, a startup movie creates a canvas
>of the appropriate size, and doesn't need a zoom... or would you rather have
>consistent behavior any time a movie is opened? Hmmm, maybe I would too.
>
>
>
>>7. Do we want to have the LOD automatically reduced when we can't meet
>>the desired frame rate? That could be a bit tricky.
>>
>>
>
>Oh, yeah - and we're supposed to drop (temporarily) to LOD 0 when we pause the
>movie, too!
>
>papillo the awake
>
>
>
>--__--__--
>
>Message: 5
>Date: Thu, 28 Aug 2003 12:10:07 -0600
>From: Brian Paul <brian@...>
>Organization: Tungsten Graphics, Inc.
>To: Robert Ellison <papillo@...>
>CC: blockbuster-devel@...
>Subject: Re: [Blockbuster-devel] What's left?
>
>Robert Ellison wrote:
>
>
>>>>1. I think we're supposed to display the current movie size (width x
>>>>height) somewhere.
>>>>
>>>>
>>A fifth status line? (Which size - original size? Region of interest
>>in pixels? Region of interest in zoomed pixels?)
>>
>>
>
>I think the full image size is what's of interest.
>
>
>
>
>>>>2. The level of detail control in the GUI doesn't work properly. It
>>>>seems to fight going to level 0 when using the 4kx4k test file.
>>>>
>>>>
>>?
>>
>>I'm not sure I'm seeing this (well, since I'm using the same file, I
>>must be seeing it, but may be interpreting it incorrectly).
>>
>>If the GUI sends back a level of detail that the application refuses to
>>acknowledge (likely if the level gets clamped), the application will
>>tell the GUI to update its level of detail value to the value being used.
>>
>>Depending on the situation, this could appear to be a "fight".
>>
>>The correct answer is to dynamically update the range of the LOD slider
>>based on the current zoom and the available levels. (Brian, I'll try to
>>figure out the math after handling a few other things; if you get to it
>>before I do, the UI call is ReportRateRangeChange(), which must be
>>checked to be non-NULL before executing.)
>>
>>
>
>If you can't find/fix it, I'll try to later.
>
>
>
>
>>>>3. The original spec calls for a slider to control zoom.
>>>>
>>>>
>>Is such still wanted? We're at the point where the toolbox is becoming
>>bigger, and I'm not sure the extra tool is useful (given that mouse
>>button 2 performs the same function).
>>
>>I know it's in the spec; we're just far enough out of spec already
>>(supporting multiple renderers & user interfaces, for example, when only
>>one was desired) and close enough to final release that I'd like to be
>>sure it's still wanted.
>>
>>But hey, it's easy enough to remove the tool if you don't want it, I
>>suppose.
>>
>>
>
>It's in the spec, so i say put it in, unless Randy and Holger say it's
>not needed.
>
>
>
>
>>>5. The frame rate slider should go to 100 at least, or have an
>>>infinity option. Perhaps a spinbox would be better. Another problem
>>>with the slider is that it's hard to make 1 fps increments/decrements
>>>since it's so short.
>>>
>>>
>>Spin box is fine with me. Maybe I'll put it in the same box with the
>>detail spinbox (saving real estate).
>>
>>
>>
>>>6. We should compute do a zoom-to-fit upon first loading a movie.
>>>
>>>
>>When loading a new movie, yes? In most cases, a startup movie creates a
>>canvas of the appropriate size, and doesn't need a zoom...
>>
>>
>
>What if the movie is much larger than the canvas/display? That's
>always the case when I view the 4Kx4K movie on my primary screen. I
>_always_ wind up hitting Zoom-to-Fit right away.
>
>
>
>
>>or would you
>>rather have consistent behavior any time a movie is opened? Hmmm, maybe
>>I would too.
>>
>>
>
>I think we should always zoom to fit initially.
>
>
>
>
>>>7. Do we want to have the LOD automatically reduced when we can't meet
>>>the desired frame rate? That could be a bit tricky.
>>>
>>>
>>Oh, yeah - and we're supposed to drop (temporarily) to LOD 0 when we
>>pause the movie, too!
>>
>>
>
>Right.
>
>-Brian
>
>
>
>--__--__--
>
>Message: 6
>Date: Thu, 28 Aug 2003 12:49:24 -0600
>From: Brian Paul <brian@...>
>Organization: Tungsten Graphics, Inc.
>To: Robert Ellison <papillo@...>
>CC: blockbuster-devel@...
>Subject: Re: [Blockbuster-devel] What's left?
>
>
>OK, DMX seems to be working again.
>
>Though, using ATI's OpenGL driver, I've found a new problem.
>Occasionally, we abort with an X protocol error that's being raised by
>ATI's libGL. I've seen this before, with Chromium.
>
>But if I run without the splashscreen, it's fine.
>
>My suspicision is that the bug is related to using multiple OpenGL
>rendering contexts & windows somehow. I'm not going to worry about it
>too much now - it's most likely an ATI bug.
>
>-Brian
>
>
>
>
>--__--__--
>
>Message: 7
>Date: Thu, 28 Aug 2003 17:07:07 -0600
>From: Robert Ellison <papillo@...>
>Organization: Tungsten Graphics
>To: blockbuster-devel@...
>Subject: [Blockbuster-devel] SM/LOD file read problem?
>
>Hi, gents -
>
>I see a strangeness when I load a LOD-savvy movie file from within Blockbuster.
>
>I start with opening a smaller image, then use "Open..." to open the 4k by 4k image.
>
>The image so loaded is corrupt, and remains so until playback begins.
>
>Any ideas from the peanut gallery?
>
>papillo the leguminous
>
>
>
>--__--__--
>
>Message: 8
>Date: Thu, 28 Aug 2003 17:19:22 -0600
>From: Brian Paul <brian@...>
>Organization: Tungsten Graphics, Inc.
>To: Robert Ellison <papillo@...>
>CC: blockbuster-devel@...
>Subject: Re: [Blockbuster-devel] SM/LOD file read problem?
>
>Robert Ellison wrote:
>
>
>>Hi, gents -
>>
>>I see a strangeness when I load a LOD-savvy movie file from within
>>Blockbuster.
>>
>>I start with opening a smaller image, then use "Open..." to open the 4k
>>by 4k image.
>>
>>The image so loaded is corrupt, and remains so until playback begins.
>>
>>Any ideas from the peanut gallery?
>>
>>
>
>Try this patch to smBase.C:
>
>
>diff -r1.10 smBase.C
>1271c1271
>< if (curwin[winnum] != f) {
>---
> > if (1 /** curwin[winnum] != f **/) {
>1282c1282
>< fprintf(stderr,"done waiting for winnum %d f %d\n",winnum,f);
>---
> > // fprintf(stderr,"done waiting for winnum %d f
>%d\n",winnum,f);
>1284c1284
>< if (curwin[winnum] != f) {
>---
> > if (1 /** curwin[winnum] != f **/) {
>
>
>I keep forgetting to send this to you, Holger. Without it, I get
>corruption too.
>
>-Brina
>
>
>
This one has me puzzled as the lockFrame prototype you've modified
should only kick in for version 1 movies or movies with no tiling. So
for backward compatibility sake I have left the original lockFrame
alone. The code that calls lockFrame
if((version == 2) && (numTiles > 1)) {
cdata = (u_char *)lockFrame((int)_f, size,
&_dim[0],&_pos[0],(int)_res);
int winnum = _f % nwin;
//fprintf(stderr,"winnum %d\n",winnum);
tbuf = (u_char *)tile_buf[winnum];
tinfo = (tileOverlapInfo_t *)tile_info[winnum];
}
else {
cdata = (u_char *)lockFrame(_f, size); <------------------ are
we landing here ???
}
Brian and Bob -- could you elaborate on when the corruption is
triggered. Did you see this prior to the openFile functionality. What
does sminfo report for your file(s) under test. Maybe the initial res
value is not being reset for the new movie as this may cause a numTiles
error. Anyhow, for test purposes I'll put an assert to always fail if I
call the older lockFrame and see what happens. I admit to not seeing
this problem with my files -- so this will be priority for me until this
is solved.
Could you give me a lockFrame trace (version 1 or version 2 printfs
during the run) if this is easily repeatable.
Holger
>
>
>--__--__--
>
>_______________________________________________
>Blockbuster-devel mailing list
>Blockbuster-devel@...
>https://lists.sourceforge.net/lists/listinfo/blockbuster-devel
>
>
>End of Blockbuster-devel Digest
>
>
>

Hi, gents -
I see a strangeness when I load a LOD-savvy movie file from within Blockbuster.
I start with opening a smaller image, then use "Open..." to open the 4k by 4k image.
The image so loaded is corrupt, and remains so until playback begins.
Any ideas from the peanut gallery?
papillo the leguminous

OK, DMX seems to be working again.
Though, using ATI's OpenGL driver, I've found a new problem.
Occasionally, we abort with an X protocol error that's being raised by
ATI's libGL. I've seen this before, with Chromium.
But if I run without the splashscreen, it's fine.
My suspicision is that the bug is related to using multiple OpenGL
rendering contexts & windows somehow. I'm not going to worry about it
too much now - it's most likely an ATI bug.
-Brian

Robert Ellison wrote:
>>> 1. I think we're supposed to display the current movie size (width x
>>> height) somewhere.
>
>
> A fifth status line? (Which size - original size? Region of interest
> in pixels? Region of interest in zoomed pixels?)
I think the full image size is what's of interest.
>>> 2. The level of detail control in the GUI doesn't work properly. It
>>> seems to fight going to level 0 when using the 4kx4k test file.
>
>
> ?
>
> I'm not sure I'm seeing this (well, since I'm using the same file, I
> must be seeing it, but may be interpreting it incorrectly).
>
> If the GUI sends back a level of detail that the application refuses to
> acknowledge (likely if the level gets clamped), the application will
> tell the GUI to update its level of detail value to the value being used.
>
> Depending on the situation, this could appear to be a "fight".
>
> The correct answer is to dynamically update the range of the LOD slider
> based on the current zoom and the available levels. (Brian, I'll try to
> figure out the math after handling a few other things; if you get to it
> before I do, the UI call is ReportRateRangeChange(), which must be
> checked to be non-NULL before executing.)
If you can't find/fix it, I'll try to later.
>>> 3. The original spec calls for a slider to control zoom.
>
>
> Is such still wanted? We're at the point where the toolbox is becoming
> bigger, and I'm not sure the extra tool is useful (given that mouse
> button 2 performs the same function).
>
> I know it's in the spec; we're just far enough out of spec already
> (supporting multiple renderers & user interfaces, for example, when only
> one was desired) and close enough to final release that I'd like to be
> sure it's still wanted.
>
> But hey, it's easy enough to remove the tool if you don't want it, I
> suppose.
It's in the spec, so i say put it in, unless Randy and Holger say it's
not needed.
>> 5. The frame rate slider should go to 100 at least, or have an
>> infinity option. Perhaps a spinbox would be better. Another problem
>> with the slider is that it's hard to make 1 fps increments/decrements
>> since it's so short.
>
>
> Spin box is fine with me. Maybe I'll put it in the same box with the
> detail spinbox (saving real estate).
>
>> 6. We should compute do a zoom-to-fit upon first loading a movie.
>
>
> When loading a new movie, yes? In most cases, a startup movie creates a
> canvas of the appropriate size, and doesn't need a zoom...
What if the movie is much larger than the canvas/display? That's
always the case when I view the 4Kx4K movie on my primary screen. I
_always_ wind up hitting Zoom-to-Fit right away.
> or would you
> rather have consistent behavior any time a movie is opened? Hmmm, maybe
> I would too.
I think we should always zoom to fit initially.
>> 7. Do we want to have the LOD automatically reduced when we can't meet
>> the desired frame rate? That could be a bit tricky.
>
>
> Oh, yeah - and we're supposed to drop (temporarily) to LOD 0 when we
> pause the movie, too!
Right.
-Brian

>> 1. I think we're supposed to display the current movie size (width x
>> height) somewhere.
A fifth status line? (Which size - original size? Region of interest in
pixels? Region of interest in zoomed pixels?)
>> 2. The level of detail control in the GUI doesn't work properly. It
>> seems to fight going to level 0 when using the 4kx4k test file.
?
I'm not sure I'm seeing this (well, since I'm using the same file, I must be
seeing it, but may be interpreting it incorrectly).
If the GUI sends back a level of detail that the application refuses to
acknowledge (likely if the level gets clamped), the application will tell the
GUI to update its level of detail value to the value being used.
Depending on the situation, this could appear to be a "fight".
The correct answer is to dynamically update the range of the LOD slider based on
the current zoom and the available levels. (Brian, I'll try to figure out the
math after handling a few other things; if you get to it before I do, the UI
call is ReportRateRangeChange(), which must be checked to be non-NULL before
executing.)
>> 3. The original spec calls for a slider to control zoom.
Is such still wanted? We're at the point where the toolbox is becoming bigger,
and I'm not sure the extra tool is useful (given that mouse button 2 performs
the same function).
I know it's in the spec; we're just far enough out of spec already (supporting
multiple renderers & user interfaces, for example, when only one was desired)
and close enough to final release that I'd like to be sure it's still wanted.
But hey, it's easy enough to remove the tool if you don't want it, I suppose.
> 5. The frame rate slider should go to 100 at least, or have an infinity
> option. Perhaps a spinbox would be better. Another problem with the
> slider is that it's hard to make 1 fps increments/decrements since it's
> so short.
Spin box is fine with me. Maybe I'll put it in the same box with the detail
spinbox (saving real estate).
> 6. We should compute do a zoom-to-fit upon first loading a movie.
When loading a new movie, yes? In most cases, a startup movie creates a canvas
of the appropriate size, and doesn't need a zoom... or would you rather have
consistent behavior any time a movie is opened? Hmmm, maybe I would too.
> 7. Do we want to have the LOD automatically reduced when we can't meet
> the desired frame rate? That could be a bit tricky.
Oh, yeah - and we're supposed to drop (temporarily) to LOD 0 when we pause the
movie, too!
papillo the awake

Brian Paul wrote:
> Robert Ellison wrote:
>
>> After a spiffy new splash screen (the old one looked terrible if it
>> popped up on a white background) and a bunch of new GTK interface
>> functionality, I'm inclined to ask what else should be done before the
>> end of month.
>>
>> - One thing comes to mind: although the Open... box works, it doesn't
>> yet have an option to easily open the last few movies. I'm planning
>> on doing this in between West Nile-induced bouts of fatigue on
>> Thursday (I guess that's today, for those of you who aren't awake yet
>> ;-).
>>
>> - As a related issue, blockbuster currently exits if opened without a
>> named movie; it seems like it would be nicer with the GTK interface if
>> blockbuster came up with an "Open File..." dialog box if no movie were
>> named. I'm planning on this as well.
>>
>> - As a user interface issue, I plan to have warnings and errors
>> reported through the GTK user interface instead of to the console (I'd
>> implemented this once before, but lost the changes before I checked
>> them in).
>>
>> - We don't support SGI RGB; this was listed in the original spec, but
>> we never confirmed it was needed (at least, as far as I'm aware, no
>> one responded to my mail of 4 August asking if that format were needed).
>>
>> - We don't support all the functionality of xmovie, in particular:
>> - Play->Stop at End
>> - Play->Swing
>> - Edit->Limits (start and stop frames)
>> - Edit->Pan-Zoom (manually set pan and zoom)
>> Are any of these required?
>>
>> So, I'm planning on implementing the first three, but not the last two
>> at this juncture. Speak now or forever hold your peace... :-)
>
>
> After reviewing things:
>
> 1. I think we're supposed to display the current movie size (width x
> height) somewhere.
>
> 2. The level of detail control in the GUI doesn't work properly. It
> seems to fight going to level 0 when using the 4kx4k test file.
>
> 3. The original spec calls for a slider to control zoom.
>
> 4. The spec calls for RGB file support. I can do that since I've got
> code for it lying around.
A few more items:
5. The frame rate slider should go to 100 at least, or have an
infinity option. Perhaps a spinbox would be better. Another problem
with the slider is that it's hard to make 1 fps increments/decrements
since it's so short.
6. We should compute do a zoom-to-fit upon first loading a movie.
7. Do we want to have the LOD automatically reduced when we can't meet
the desired frame rate? That could be a bit tricky.
-Brian

Robert Ellison wrote:
> After a spiffy new splash screen (the old one looked terrible if it
> popped up on a white background) and a bunch of new GTK interface
> functionality, I'm inclined to ask what else should be done before the
> end of month.
>
> - One thing comes to mind: although the Open... box works, it doesn't
> yet have an option to easily open the last few movies. I'm planning on
> doing this in between West Nile-induced bouts of fatigue on Thursday (I
> guess that's today, for those of you who aren't awake yet ;-).
>
> - As a related issue, blockbuster currently exits if opened without a
> named movie; it seems like it would be nicer with the GTK interface if
> blockbuster came up with an "Open File..." dialog box if no movie were
> named. I'm planning on this as well.
>
> - As a user interface issue, I plan to have warnings and errors reported
> through the GTK user interface instead of to the console (I'd
> implemented this once before, but lost the changes before I checked them
> in).
>
> - We don't support SGI RGB; this was listed in the original spec, but we
> never confirmed it was needed (at least, as far as I'm aware, no one
> responded to my mail of 4 August asking if that format were needed).
>
> - We don't support all the functionality of xmovie, in particular:
> - Play->Stop at End
> - Play->Swing
> - Edit->Limits (start and stop frames)
> - Edit->Pan-Zoom (manually set pan and zoom)
> Are any of these required?
>
> So, I'm planning on implementing the first three, but not the last two
> at this juncture. Speak now or forever hold your peace... :-)
After reviewing things:
1. I think we're supposed to display the current movie size (width x
height) somewhere.
2. The level of detail control in the GUI doesn't work properly. It
seems to fight going to level 0 when using the 4kx4k test file.
3. The original spec calls for a slider to control zoom.
4. The spec calls for RGB file support. I can do that since I've got
code for it lying around.
-Brian

After a spiffy new splash screen (the old one looked terrible if it popped up on
a white background) and a bunch of new GTK interface functionality, I'm inclined
to ask what else should be done before the end of month.
- One thing comes to mind: although the Open... box works, it doesn't yet have
an option to easily open the last few movies. I'm planning on doing this in
between West Nile-induced bouts of fatigue on Thursday (I guess that's today,
for those of you who aren't awake yet ;-).
- As a related issue, blockbuster currently exits if opened without a named
movie; it seems like it would be nicer with the GTK interface if blockbuster
came up with an "Open File..." dialog box if no movie were named. I'm planning
on this as well.
- As a user interface issue, I plan to have warnings and errors reported through
the GTK user interface instead of to the console (I'd implemented this once
before, but lost the changes before I checked them in).
- We don't support SGI RGB; this was listed in the original spec, but we never
confirmed it was needed (at least, as far as I'm aware, no one responded to my
mail of 4 August asking if that format were needed).
- We don't support all the functionality of xmovie, in particular:
- Play->Stop at End
- Play->Swing
- Edit->Limits (start and stop frames)
- Edit->Pan-Zoom (manually set pan and zoom)
Are any of these required?
So, I'm planning on implementing the first three, but not the last two at this
juncture. Speak now or forever hold your peace... :-)
papillo the morbid
Bob Ellison, Tungsten Graphics, Inc.

Hi, all -
First pass for the GTK 1.2 user interface is in place, if you'd like to see it.
Of note:
- You can now specify any combination of "-u <userInterface>" and "-r
<renderer>". If you specify just a user interface, you get its preferred
renderer. If you specify just a renderer, you get the first user interface that
supports that renderer. If you specify both, you get both (if a valid
combination exists). If you specify neither, you get the preferred renderer of
the first user interface.
The first user interface is "gtk", and its preferred renderer is "gltexture".
We can adjust this easily.
You can still get to the simpler X11 user interface with "-ux11". (Is it
confusing to have both an "x11" user interface and an "x11" renderer? We can
rename one...)
- The "gtk" user interface inherits a lot from the X11 user interface; you can
still use all the keyboard and mouse controls in the graphics window. Be aware
that if you "Hide" the GTK controls window, you can use "i" in the graphics
window (for "interface") to bring it back (it's a toggle - another "i" will turn
it off again).
- The GTK 1.2 widgets are more boring than GTK 2.0. In particular, there are no
stock images. Should we take a stab at adding graphics, or is the text button
interface sufficient?
- We've got sliders for current frame, and for frame rate; and a spin button for
the level of detail. All of these will soon have automatic range limits set (as
soon as Brian and I can agree on what those should be ;-).
- The "Open..." button doesn't work yet, but will tomorrow (barring severe West
Nile fatigue...)
Anything else missing from the UI? Would y'all like a "Zoom" slider? A spin
button instead of a slider for frame rate?
A screenshot is attached for your perusal...
papillo the egyptologist
Bob Ellison, Tungsten Graphics, Inc.

> Is there supposed to be a gtk.c source file? Linking fails, complaining
> that gtk.o is not found.
That's the file I blew away while making diff's. :-(
The checked-in Makefile should have GTK turned off, which allows you to link and
run using the X11 user interface.
papillo the clumsy

Robert Ellison wrote:
>> Is there supposed to be a gtk.c source file? Linking fails,
>> complaining that gtk.o is not found.
>
>
> That's the file I blew away while making diff's. :-(
>
> The checked-in Makefile should have GTK turned off, which allows you to
> link and run using the X11 user interface.
Ah, OK, I misread what you had wrote.
I often check in source files before they're complete - just in case.
-Brian

Brian Paul wrote:
>
> The situation I was thinking of is if I'm reading [100,100]->[400,400]
> of a much larger image, say 4K x 4K. Looking at the current code, I
> guess it wouldn't be a win (except perhaps if we're panning).
>
> Are you interested in suggestions to speed-up the code around lines
> 975..1000 in smBase.C? I see a few things.
>
> -Brian
>
>
Sure, any optimizations are welcome. However, I'm still getting 3x
factor in framerate in smtest vs blockbuster. So, although you've
admitted that we're at the I/O wall, I still see some headroom ;) Also,
I've noticed contrary to my earlier suggestion that increasing nwin
(which sets up preallocated buffers for reader threads) has no effect on
I/O performance, so forget that suggestion. smtest, usually doubles in
framerate dramatically when going from nwin == 1 to 2. Also, xmovie
which is throttled at 30fps easily maintains this rate (30fps) for a
1kx1k movie, while blockbuster hovers around 15 -20 fps. BTW, xmovie is
utilizing the current smBase lib. Just food for thought.
Holger

> With my latest check-ins, DMX mode is working again. I doubt if the
> fake DMX support is working anymore - I haven't touched it in a while.
Thanks - that means I don't have to use the fake DMX for now. (Although I would
like to play with it sometime...)
papillo the grateful

Robert Ellison wrote:
[...]
> The merge was significant; I've tried hard not to break the other code
> (specifically the DMX code), but I am still unable to test that
> particular renderer, even though the "fake DMX" mode should work. I'll
> get with Brian to see whether he has more testing time available (I
> believe he's overboard already) and to work out an alternative if he
> doesn't.
With my latest check-ins, DMX mode is working again. I doubt if the
fake DMX support is working anymore - I haven't touched it in a while.
-Brian

Robert Ellison wrote:
> One high fever and considerable systemic distress later (have you had
> *your* West Nile virus today? :-(), I'm baaaack...
>
> I've just checked in a pervasive change: the isolation of the concept of
> "user interface" to its own "UserInterface" object, its separation from
> the congenital "Renderer" objects, and the formal interface between the
> two.
>
> These changes really are just a formalization and extension of the nice
> work Brian did to pull the X11 stuff out of the Renderers and into their
> own module. The minimal "glue" needed by each Renderer is now isolated,
> making it easier to access existing Renderers in new UserInterfaces.
>
> Although this is technically out of spec (as we didn't initially plan on
> supporting multiple UserInterfaces), I chose to make the changes because
> it not only makes the implementation of a GTK UI significantly less
> complex (and thereby less risky), but it opens up the possibility of
> adding other UI interfaces (such as a scripting user interface, or a
> "ActiveX" user interface, etc.) with much greater ease. I think it
> makes the product better, and will ultimately be a good return on effort
> investment. (Perhaps we should have included this in the original
> specification.)
>
> It is late in the schedule to be making such a change; I appreciate the
> risk involved (especially since it puts me in particular very much
> "under the gun"), but still believe this to be the "right idea".
>
> (I'd love to generalize the current "slave mode", used by DMX to control
> the remote players, into its own UserInterface; but that's definitely
> beyond the resources we have. Perhaps in a follow-on project, while
> adding scripting... ;-)
>
> The merge was significant; I've tried hard not to break the other code
> (specifically the DMX code), but I am still unable to test that
> particular renderer, even though the "fake DMX" mode should work. I'll
> get with Brian to see whether he has more testing time available (I
> believe he's overboard already) and to work out an alternative if he
> doesn't.
>
> A misstep during the merge, unfortunately, took out my local copy of the
> "GTK interface in a window" implementation (with my last backup a couple
> of days old and nearly useless; I hate it when I'm an idiot on multiple
> fronts). Fortunately, it wasn't that complex, and it's relatively fresh
> in mind. I plan to have it done by this same time tomorrow (i.e.,
> depending on how you read it, very late Monday nite or very early
> Tuesday morning).
>
> Be aware, if you're working with one of the GetEvents() implementations,
> that it's now much more like X11; you GetEvent() with a pointer to a
> MovieEvent structure, and get the MovieEventType and any extra data back
> in that structure. (I needed to expand the MovieEvent to include a
> filename for the MOVIE_LOAD_FILE event, and this seemed like the best
> way to do it for the future...)
>
> I promise no more architectural during this project.
Is there supposed to be a gtk.c source file? Linking fails,
complaining that gtk.o is not found.
-Brian

One high fever and considerable systemic distress later (have you had *your*
West Nile virus today? :-(), I'm baaaack...
I've just checked in a pervasive change: the isolation of the concept of "user
interface" to its own "UserInterface" object, its separation from the congenital
"Renderer" objects, and the formal interface between the two.
These changes really are just a formalization and extension of the nice work
Brian did to pull the X11 stuff out of the Renderers and into their own module.
The minimal "glue" needed by each Renderer is now isolated, making it easier
to access existing Renderers in new UserInterfaces.
Although this is technically out of spec (as we didn't initially plan on
supporting multiple UserInterfaces), I chose to make the changes because it not
only makes the implementation of a GTK UI significantly less complex (and
thereby less risky), but it opens up the possibility of adding other UI
interfaces (such as a scripting user interface, or a "ActiveX" user interface,
etc.) with much greater ease. I think it makes the product better, and will
ultimately be a good return on effort investment. (Perhaps we should have
included this in the original specification.)
It is late in the schedule to be making such a change; I appreciate the risk
involved (especially since it puts me in particular very much "under the gun"),
but still believe this to be the "right idea".
(I'd love to generalize the current "slave mode", used by DMX to control the
remote players, into its own UserInterface; but that's definitely beyond the
resources we have. Perhaps in a follow-on project, while adding scripting... ;-)
The merge was significant; I've tried hard not to break the other code
(specifically the DMX code), but I am still unable to test that particular
renderer, even though the "fake DMX" mode should work. I'll get with Brian to
see whether he has more testing time available (I believe he's overboard
already) and to work out an alternative if he doesn't.
A misstep during the merge, unfortunately, took out my local copy of the "GTK
interface in a window" implementation (with my last backup a couple of days old
and nearly useless; I hate it when I'm an idiot on multiple fronts).
Fortunately, it wasn't that complex, and it's relatively fresh in mind. I plan
to have it done by this same time tomorrow (i.e., depending on how you read it,
very late Monday nite or very early Tuesday morning).
Be aware, if you're working with one of the GetEvents() implementations, that
it's now much more like X11; you GetEvent() with a pointer to a MovieEvent
structure, and get the MovieEventType and any extra data back in that structure.
(I needed to expand the MovieEvent to include a filename for the
MOVIE_LOAD_FILE event, and this seemed like the best way to do it for the future...)
I promise no more architectural during this project.
papillo the perfectionist
Bob Ellison, Tungsten Graphics

Holger Jones wrote:
> Hi Gang:
>
> I've checked in some changes to smBase.C which address the tile caching
> issue when you call getFrameBlock with the same frame number. As you pan
> it will bring in only the newly overlapping tiles. Still needs to be
> exercised fully (I need to modify smtest) but definitely worth checking
> in. Also, while debugging this I noticed that when I set cache and
> preloads to > 1 , I actually spotted sync issues between two of the
> reader threads -- i.e. winlock within lockFrame went to a value of 2, at
> which point getFrameBlock would segfault (lockFrame wasn't doing its job
> -- behavior was confusing to say the least). I modified lockFrame
> semantics somewhat -- which should address Brian's earlier hack on
> that routine. The reason I noticed this behavior is that nwin was set
> to one even though two threads seemed to be banging on getFrameBlock. I
> would recommend setting nwin to the expected number of reader threads;
> similar to the way smtest uses it.
>
> Brian, I apologize if this checkin conflicts with your earlier smBase.C
> post - I did not see your message until after I made the commits.
>
> Also, it looks like you've got most of the LOD behavior nailed. Things
> are working really smooth -- at least on my home machine (using -r x11).
> Very nice!!!
Things should be smoother yet with today's check-ins.
> Also to address Brian's earlier comment regarding reading on tile
> boundaries -- you won't notice much difference when reading a sub block
> of say from [100,100]->[400,400] of a 500x500 MipMap if the tiles are
> 256x256 -- in this case all tiles overlap and so must be decompressed.
Right, but that's not what I had in mind.
> The copy to the caller's block will be slightly faster though since
> we're only moving a 300x300 block. However [0,0] -> [255,500] has only
> half of the tiles overlapping so its a big win. You certainly want to be
> cognizant of this at extreme zoom factors of 3+.
The situation I was thinking of is if I'm reading [100,100]->[400,400]
of a much larger image, say 4K x 4K. Looking at the current code, I
guess it wouldn't be a win (except perhaps if we're panning).
Are you interested in suggestions to speed-up the code around lines
975..1000 in smBase.C? I see a few things.
-Brian

Hi Gang:
I've checked in some changes to smBase.C which address the tile caching
issue when you call getFrameBlock with the same frame number. As you pan
it will bring in only the newly overlapping tiles. Still needs to be
exercised fully (I need to modify smtest) but definitely worth checking
in. Also, while debugging this I noticed that when I set cache and
preloads to > 1 , I actually spotted sync issues between two of the
reader threads -- i.e. winlock within lockFrame went to a value of 2, at
which point getFrameBlock would segfault (lockFrame wasn't doing its job
-- behavior was confusing to say the least). I modified lockFrame
semantics somewhat -- which should address Brian's earlier hack on
that routine. The reason I noticed this behavior is that nwin was set
to one even though two threads seemed to be banging on getFrameBlock. I
would recommend setting nwin to the expected number of reader threads;
similar to the way smtest uses it.
Brian, I apologize if this checkin conflicts with your earlier smBase.C
post - I did not see your message until after I made the commits.
Also, it looks like you've got most of the LOD behavior nailed. Things
are working really smooth -- at least on my home machine (using -r x11).
Very nice!!!
Also to address Brian's earlier comment regarding reading on tile
boundaries -- you won't notice much difference when reading a sub block
of say from [100,100]->[400,400] of a 500x500 MipMap if the tiles are
256x256 -- in this case all tiles overlap and so must be decompressed.
The copy to the caller's block will be slightly faster though since
we're only moving a 300x300 block. However [0,0] -> [255,500] has only
half of the tiles overlapping so its a big win. You certainly want to be
cognizant of this at extreme zoom factors of 3+.
Holger

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details