QuickTime conundrum

xbury.cs at clearstream.com xbury.cs at clearstream.com
Mon Mar 14 08:38:43 EST 2005


Richard,

I think I found the problem... It is not with Runrev entirely but more 
likely with 
QuickTime!!! I tested it against mplayer32, winamp video or mediaplayer
and only QT has this problem! I didn't play with QT's video system 
settings.

All is by default...

Open a couple apps in Windows. Any of them being Quicktime. 
Start playing the movie...

In the taskbar, rightclick the application left of QT and when that 
contextmenu
will show, you will see the shadow of the menu fliquer like the menus did 
in 
RunRev.

--

Quicktime's implementations on windows have been more than crappy and 
buggy than anything else I've seen doing videos on Windows, so im not 
surprised... I've seen the same on Macs with Mis Office... ;)

Then again, it could be the dark side causing this too or Steve thinks 
that 
users of quicktime will migrate to mac when they see a good app running 
on a (by public default) bad os...

Of the dozens of different video players available on PCs, we're stuck 
with the 
very worst of the bunch! But it's better than none! ;) And Apple has 
improved QT
over and over to make it less nightmarish than it was before 6.x! But 
after 6
versions they still can't make a player that doesn't fliquer if there's 
anything on
top! Definitely not what is going to convert me back to macs or QT!

It may be possible to turn of the shading feature automatically via a 
registry
manipulations and/or wsh or vbs scritps... Or it may be possible to write 
a
directdraw external to deal away without QT...

Another solution would be to use AltBrowser and display a "real" player 
object
via Windows ActiveX controls... Although I haven't played wih AltBrowser 
it 
seems doable...

cheers
Xavier


On 14.03.2005 13:58:10 use-revolution-bounces wrote:
>Slight oversight... I was sure I had this option off but it wasn't on 
this
>computer...
>
>Removing the menus' shadows in windows (rightclick desktop, choose
>tab Appearance, btn Effects and remove all the options...)
>
>This improves the playback (although unrealistic to ask this to clients!)
>Note that when switching from one menu to another causes a flash or
>blip (whichever you prefer) in the player's window!
>
>But most of the "display" problems mentioned before are gone...
>
>cheers
>Xavier
>
>On 14.03.2005 09:13:40 use-revolution-bounces wrote:
>>Although I never got a test stack to crash, or freeze (2 cpus didn't 
help
>>the flicker or ailing menu response!).
>>
>>But dragging a control over the player is also a big show of problems!
>>Even more so without the alwaysbuffer... (BTW, if I set the alwaysbuffer
>>to true I can no longuer play the movie via the controls!
>>
>>Switching XP themes to Windows classic  didn't help but i did notice 
part
>>of
>>the problem.... The shading of the menus! I turned it off in windows and
>>it's still
>>showing...
>>
>>Another one to add along with many other windows properties being 
ignored
>>until you restart RR... Is it the same for Macs?
>>
>>Cheers
>>Xavier
>>
>>
>>On 14.03.2005 08:40:24 use-revolution-bounces wrote:
>>>I filed a bug report this weekend for this anomaly with QuickTime and
>>>menus - Windows only:
>>>
>>>Hold the mouse down over the menubar to pop down the menus,
>>>esp the submenu in Edit.  When a QT movie is assigned to
>>>the player the movie flickers.  If you play with it enough
>>>you'll get in some sort of loop that consumes 100% of CPU
>>>and is hard to break out of.
>>><http://support.runrev.com/bugdatabase/show_bug.cgi?id=2692>
>>>
>>>There's a sample stack there which exhibits the behavior, but it's easy
>>>to make one:
>>>
>>>Just put a menu group in a stack, then put a player there.  Give one of
>>>your menus a submenu -- the more items the better.  Then put a player 
on
>>>the card, assign it a movie (the longer the better) and try to select
>>>something from the submenu.
>>>
>>>What happens appears to be some sort of loop in which the menus (esp.
>>>the submenu, as it's much more noticeable there) is fighting with QT 
for
>>>redraw time -- whenever you drag the mouse over another menu or submenu
>>>the player flickers, and the menu takes a long time to draw.  Drag
>>>across multiple menus and you may well trigger a loop that you may need
>>>to force quit to get out of.
>>>
>>>I just tried my experiment using Rev's menus, and the same thing
>happens:
>>>
>>>1. Make a new stack
>>>2. Put a player in it
>>>3. Assign a movie to the player
>>>4. Drag the mouse across the Rev menubar and down some menus to '
>>>bring up submenus -- I got a freeze
>>>
>>>I'm hoping to find some magic combination of properties to help
>>>alleviate this.  Unfortunately I must have the player's controller
>>>available, so simply turning on the player's alwaysBuffer -- while it
>>>does improve things -- won't work in this app.
>>>
>>>Any clues?
>>>
>>>Alas, it seems half of my life is consumed with anomalies related to
>>>QuickTime.... ::sigh::
>>
>>
>
>
>-----------------------------------------
>Visit us at http://www.clearstream.com
>IMPORTANT MESSAGE    Internet communications are not secure and therefore
>Clearstream International does not accept legal responsibility for the
>contents of this message.    The information contained in this e-mail is
>confidential and may be legally privileged. It is intended solely for the
>addressee. If you are not the intended recipient, any disclosure, 
copying,
>distribution or any action taken or omitted to be taken in reliance on 
it,
>is prohibited and may be unlawful. Any views expressed in this e-mail are
>those of the individual sender, except where the sender specifically 
states
>them to be the views of Clearstream International or of any of its
>affiliates or subsidiaries.    END OF DISCLAIMER
>_______________________________________________
>use-revolution mailing list
>use-revolution at lists.runrev.com
>http://lists.runrev.com/mailman/listinfo/use-revolution


More information about the use-livecode mailing list