This posting is older than 6 months and can contain outdated information.
Thanks for asking.
I'm afraid that this is not really a Remote Buddy specific problem (as
all Remote Buddy does is open a translucent window - so nothing
unusual, really), but more of a performance problem of the chipset
graphics of the MacBook.
OS X graphics system utilizes OpenGL a lot to offload work to the
graphics hardware. That, however, also means that it'll store as much
graphics data as possible in the graphics memory, so that rendering is
as smooth as possible (=> that's also why you'll find 512 MB and more
on modern graphics cards compared to the 8 MB or 32 MB there used to
be. Back then, the memory's main use was as a frame buffer, now a lot
of textures need to be stored there as well).
Now, the higher the resolution you use, the more graphics memory will
be needed and - especially with chipset graphics (where CPU and GPU
share the same bus, but can't access concurrently, thus effectively
slowing down one another) - the more data will need to be shuffled in
and out of the graphics memory.
When increasing screen resolution and adding a second display, at some
point you're guaranteed to hit a bottleneck (memory, bus or otherwise)
and that's when you see performance degrading. It seems your system
operates close to that bottleneck already and that when you start
Remote Buddy, the small amount of graphics memory it needs finally
pushes the integrated graphics of your system beyond its limits and
the bottleneck is finally hit.
That's also why you'll see zero choppiness with a smaller EyeTV window
(=> less graphics memory needed, less data shuffled across the bus)
vs. a full-screen EyeTV window (=> more graphics memory is needed,
more data is shuffled across the bus).
EyeTV will need more resources than VLC, because it needs to do a lot
more. While VLC "just" plays back material that's "ready for display"
right after decompression, EyeTV has to deal with tasks like
deinterlacing (putting together the half frames it gets from the video
signal), which means it needs to do some processing on the
decompressed data prior to being able to display it - which is prone
to need both more (video) memory and CPU power.
Possible solutions:
- reduce the resolution on your external or internal display (=> keep
in mind that, unless you receive HDTV, standard PAL/NTSC video has a
resolution of around 760 x 540)
- turn off any effects you may have configured in Remote Buddy
Preferences > Menu > Appearance. These all use Core Image and thus
indirectly put more load (when fading in/out) and possibly more
resource use on your graphics system
- set a (small) desktop background image consisting of only one color.
Texture compression on the GPU will make sure the amount of memory
needed to store that background is minimal vs. a photo as a
background, which will not nearly compress as much.
- try turning off deinterlacing in EyeTV (may or may not show effect -
I write that under the assumption that this may save some graphics
memory and traffic between CPU and the memory on the bus)
Best regards,
Felix Schwarz
