[sip-comm-dev] How to switch off desktop streaming


#1

How to switch of desktop streaming?

When trying to set the media configuration the preview window shows
my desktop. Similar to the audio interface the video interface
seems to offer a selection to switch between video sources.
However, it seems that it does not offer "None". In additon
the desktop streaming in the during preview slows down the
desktop, I can't even move a window. Switching between windows
is also quite slow. After closing the media configuration
anything seems to go to normal.

SC SVN revision 6783, fresh rebuild
OpenSuse, KDE 4.3.1

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hi Werner,

On my desktop I can choose "No device" in the list but maybe item is masked by the current video preview (Java heavyweight/lightweight Component mix). Try to play with "down" arrow to select other choices (No device or other video capture device).

For the desktop streaming slowdown I think it is related to your Xorg driver that do not support X Shared Memory extensions (XSHM). What graphics card/driver do you use ?

Regards,

···

--
Seb

Werner Dittmann a �crit :

How to switch of desktop streaming?

When trying to set the media configuration the preview window shows
my desktop. Similar to the audio interface the video interface
seems to offer a selection to switch between video sources.
However, it seems that it does not offer "None". In additon
the desktop streaming in the during preview slows down the
desktop, I can't even move a window. Switching between windows
is also quite slow. After closing the media configuration
anything seems to go to normal.

SC SVN revision 6783, fresh rebuild
OpenSuse, KDE 4.3.1

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Seb, see inline

Hi Werner,

On my desktop I can choose "No device" in the list but maybe item is
masked by the current video preview (Java heavyweight/lightweight
Component mix). Try to play with "down" arrow to select other choices
(No device or other video capture device).

Thanks, playing with arrow keys work, but it is inconvenient :slight_smile: because
no optical feedback

For the desktop streaming slowdown I think it is related to your Xorg
driver that do not support X Shared Memory extensions (XSHM). What
graphics card/driver do you use ?

I've a fairly new ATI 4650 and I use the proprietary ATI fglrx driver.
I used Mplayer to check if the x11 drivers worka. The follwing mplayer
video out drivers work on my system:

mplayer -vo x11 file.avi
mplayer -vo xv file.avi
mplayer -vo gl file.avi
mplayer -vo gl2 file.avi

The first driver (x11) uses shared memory according to mplayer documentation.
Do I need to configure something in SC?

When using SC and selecting the media configuration and have the desktop
preview then SC currently uses ~2GB of main memnory and nearly all CPU cycles.

Regards,
Werner

···

Am 22.02.2010 08:30, schrieb Sebastien Vincent:

Regards,
--
Seb

Werner Dittmann a �crit :

How to switch of desktop streaming?

When trying to set the media configuration the preview window shows
my desktop. Similar to the audio interface the video interface
seems to offer a selection to switch between video sources.
However, it seems that it does not offer "None". In additon
the desktop streaming in the during preview slows down the
desktop, I can't even move a window. Switching between windows
is also quite slow. After closing the media configuration
anything seems to go to normal.

SC SVN revision 6783, fresh rebuild
OpenSuse, KDE 4.3.1

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Seb,

just as additional info. SC prints out the following lines at
my console if I start SC via "ant run":

     [java] BasicTrackControl:prefetchTrack():96 2 bm = com.sun.media.BasicFilterModule@1b9b7dfa
     [java] BasicTrackControl:prefetchTrack():96 2 bm = com.sun.media.BasicRendererModule@7d6bb63e
     [java] BasicRendererModule.doPrefetch:155 Render : true
     [java] BasicRenderModule.doPrefetch:159 Render : com.sun.media.renderer.video.AWTRenderer@52db59df
     [java] BasicTrackControl:prefetchTrack():96 2 bm = com.sun.media.BasicFilterModule@4b5d7792
     [java] BasicTrackControl:prefetchTrack():96 2 bm = com.sun.media.BasicRendererModule@655538e5
     [java] BasicRendererModule.doPrefetch:155 Render : true
     [java] BasicRenderModule.doPrefetch:159 Render : com.sun.media.renderer.video.AWTRenderer@3be5d207
     [java] BasicTrackControl:prefetchTrack():96 2 bm = com.sun.media.BasicFilterModule@591f5ff9
     [java] BasicTrackControl:prefetchTrack():96 2 bm = com.sun.media.BasicRendererModule@1ad60225
     [java] BasicRendererModule.doPrefetch:155 Render : true
     [java] BasicRenderModule.doPrefetch:159 Render : com.sun.media.renderer.video.AWTRenderer@4e7f3159

Regards,
Werner

···

Am 22.02.2010 08:30, schrieb Sebastien Vincent:

Hi Werner,

On my desktop I can choose "No device" in the list but maybe item is
masked by the current video preview (Java heavyweight/lightweight
Component mix). Try to play with "down" arrow to select other choices
(No device or other video capture device).

For the desktop streaming slowdown I think it is related to your Xorg
driver that do not support X Shared Memory extensions (XSHM). What
graphics card/driver do you use ?

Regards,
--
Seb

Werner Dittmann a �crit :

How to switch of desktop streaming?

When trying to set the media configuration the preview window shows
my desktop. Similar to the audio interface the video interface
seems to offer a selection to switch between video sources.
However, it seems that it does not offer "None". In additon
the desktop streaming in the during preview slows down the
desktop, I can't even move a window. Switching between windows
is also quite slow. After closing the media configuration
anything seems to go to normal.

SC SVN revision 6783, fresh rebuild
OpenSuse, KDE 4.3.1

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hi Werner.

Werner Dittmann a �crit :

Seb, see inline

Hi Werner,

On my desktop I can choose "No device" in the list but maybe item is
masked by the current video preview (Java heavyweight/lightweight
Component mix). Try to play with "down" arrow to select other choices
(No device or other video capture device).
    

Thanks, playing with arrow keys work, but it is inconvenient :slight_smile: because
no optical feedback

For the desktop streaming slowdown I think it is related to your Xorg
driver that do not support X Shared Memory extensions (XSHM). What
graphics card/driver do you use ?
    

I've a fairly new ATI 4650 and I use the proprietary ATI fglrx driver.
I used Mplayer to check if the x11 drivers worka. The follwing mplayer
video out drivers work on my system:

mplayer -vo x11 file.avi
mplayer -vo xv file.avi
mplayer -vo gl file.avi
mplayer -vo gl2 file.avi

The first driver (x11) uses shared memory according to mplayer documentation.
Do I need to configure something in SC?
  

Normally not.

Do you see some kind of freezing of desktop when desktop streaming is enabled in preview ? If yes the JNI does not use XSHM. The JNI first try to use XSHM and fallback to standard XGetImage if there were errors (either if XSHM is unsupported by X Server or shared memory allocation error/XShmGetImage failure.

On a virtualized FreeBSD (VirtualBox), I experiment that XShm was supported but XShmGetImage fail. But I think that is was because of the "virtualization".

If you have technical skills in C you could try to see where the code is failing in src/native/screencapture/net_java_sip_communicator_impl_neomedia_imgstreaming_NativeScreenCapture.c. The function is x11_grab_screen. I will see again with my FreeBSD if it still fail on XShmGetImage.

When using SC and selecting the media configuration and have the desktop
preview then SC currently uses ~2GB of main memnory and nearly all CPU cycles.

Hmm it is high values, I don't have these value for NVidia (with proprietary driver) and intel (with Xorg driver) so maybe it is because of XShm is not used (or fail).

···

Am 22.02.2010 08:30, schrieb Sebastien Vincent:

--
Seb

Regards,
Werner

Regards,
--
Seb

Werner Dittmann a �crit :
    

How to switch of desktop streaming?

When trying to set the media configuration the preview window shows
my desktop. Similar to the audio interface the video interface
seems to offer a selection to switch between video sources.
However, it seems that it does not offer "None". In additon
the desktop streaming in the during preview slows down the
desktop, I can't even move a window. Switching between windows
is also quite slow. After closing the media configuration
anything seems to go to normal.

SC SVN revision 6783, fresh rebuild
OpenSuse, KDE 4.3.1

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Werner Dittmann a �crit :

Seb, see inline

Hi Werner,

On my desktop I can choose "No device" in the list but maybe item is
masked by the current video preview (Java heavyweight/lightweight
Component mix). Try to play with "down" arrow to select other choices
(No device or other video capture device).
    

Thanks, playing with arrow keys work, but it is inconvenient :slight_smile: because
no optical feedback
  
We can disable "lightweight" property of a JComboBox with the patch attached. Tell me if it works for you.
I think it is safe to commit after if it works.

Regards,

sc-lightweight.diff (658 Bytes)

···

Am 22.02.2010 08:30, schrieb Sebastien Vincent:

--
Seb

For the desktop streaming slowdown I think it is related to your Xorg
driver that do not support X Shared Memory extensions (XSHM). What
graphics card/driver do you use ?
    

I've a fairly new ATI 4650 and I use the proprietary ATI fglrx driver.
I used Mplayer to check if the x11 drivers worka. The follwing mplayer
video out drivers work on my system:

mplayer -vo x11 file.avi
mplayer -vo xv file.avi
mplayer -vo gl file.avi
mplayer -vo gl2 file.avi

The first driver (x11) uses shared memory according to mplayer documentation.
Do I need to configure something in SC?

When using SC and selecting the media configuration and have the desktop
preview then SC currently uses ~2GB of main memnory and nearly all CPU cycles.

Regards,
Werner

Regards,
--
Seb

Werner Dittmann a �crit :
    

How to switch of desktop streaming?

When trying to set the media configuration the preview window shows
my desktop. Similar to the audio interface the video interface
seems to offer a selection to switch between video sources.
However, it seems that it does not offer "None". In additon
the desktop streaming in the during preview slows down the
desktop, I can't even move a window. Switching between windows
is also quite slow. After closing the media configuration
anything seems to go to normal.

SC SVN revision 6783, fresh rebuild
OpenSuse, KDE 4.3.1

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Hi Seb,

I tested at my side and it works ok on my Linux machine.

Cheers
damencho

···

On Tue, Feb 23, 2010 at 4:07 PM, Sebastien Vincent <seb@sip-communicator.org > wrote:

Werner Dittmann a écrit :

Seb, see inline

Am 22.02.2010 08:30, schrieb Sebastien Vincent:

Hi Werner,

On my desktop I can choose "No device" in the list but maybe item is
masked by the current video preview (Java heavyweight/lightweight
Component mix). Try to play with "down" arrow to select other choices
(No device or other video capture device).

Thanks, playing with arrow keys work, but it is inconvenient :slight_smile: because
no optical feedback

We can disable "lightweight" property of a JComboBox with the patch
attached. Tell me if it works for you.
I think it is safe to commit after if it works.

Regards,
--
Seb

For the desktop streaming slowdown I think it is related to your Xorg
driver that do not support X Shared Memory extensions (XSHM). What
graphics card/driver do you use ?

I've a fairly new ATI 4650 and I use the proprietary ATI fglrx driver.
I used Mplayer to check if the x11 drivers worka. The follwing mplayer
video out drivers work on my system:

mplayer -vo x11 file.avi
mplayer -vo xv file.avi
mplayer -vo gl file.avi
mplayer -vo gl2 file.avi

The first driver (x11) uses shared memory according to mplayer
documentation.
Do I need to configure something in SC?

When using SC and selecting the media configuration and have the desktop
preview then SC currently uses ~2GB of main memnory and nearly all CPU
cycles.

Regards,
Werner

Regards,
--
Seb

Werner Dittmann a écrit :

How to switch of desktop streaming?

When trying to set the media configuration the preview window shows
my desktop. Similar to the audio interface the video interface
seems to offer a selection to switch between video sources.
However, it seems that it does not offer "None". In additon
the desktop streaming in the during preview slows down the
desktop, I can't even move a window. Switching between windows
is also quite slow. After closing the media configuration
anything seems to go to normal.

SC SVN revision 6783, fresh rebuild
OpenSuse, KDE 4.3.1

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

Damian Minkov a �crit :

Hi Seb,

I tested at my side and it works ok on my Linux machine.

I tested on Windows 32-bit and Mac OS X 10.5 (Leopard) 32-bit and it is working fine. I will commit after a final test on Windows x64.

···

--
Seb

Cheers
damencho

On Tue, Feb 23, 2010 at 4:07 PM, Sebastien Vincent > <seb@sip-communicator.org <mailto:seb@sip-communicator.org>> wrote:

    Werner Dittmann a �crit :

        Seb, see inline

        Am 22.02.2010 08:30, schrieb Sebastien Vincent:
         
            Hi Werner,

            On my desktop I can choose "No device" in the list but
            maybe item is
            masked by the current video preview (Java
            heavyweight/lightweight
            Component mix). Try to play with "down" arrow to select
            other choices
            (No device or other video capture device).
               
        Thanks, playing with arrow keys work, but it is inconvenient
        :-) because
        no optical feedback
         
    We can disable "lightweight" property of a JComboBox with the
    patch attached. Tell me if it works for you.
    I think it is safe to commit after if it works.

    Regards,
    --
    Seb

            For the desktop streaming slowdown I think it is related
            to your Xorg
            driver that do not support X Shared Memory extensions
            (XSHM). What
            graphics card/driver do you use ?
               
        I've a fairly new ATI 4650 and I use the proprietary ATI fglrx
        driver.
        I used Mplayer to check if the x11 drivers worka. The follwing
        mplayer
        video out drivers work on my system:

        mplayer -vo x11 file.avi
        mplayer -vo xv file.avi
        mplayer -vo gl file.avi
        mplayer -vo gl2 file.avi

        The first driver (x11) uses shared memory according to mplayer
        documentation.
        Do I need to configure something in SC?

        When using SC and selecting the media configuration and have
        the desktop
        preview then SC currently uses ~2GB of main memnory and nearly
        all CPU cycles.

        Regards,
        Werner

            Regards,
            -- Seb

            Werner Dittmann a �crit :
               
                How to switch of desktop streaming?

                When trying to set the media configuration the preview
                window shows
                my desktop. Similar to the audio interface the video
                interface
                seems to offer a selection to switch between video
                sources.
                However, it seems that it does not offer "None". In
                additon
                the desktop streaming in the during preview slows down the
                desktop, I can't even move a window. Switching between
                windows
                is also quite slow. After closing the media configuration
                anything seems to go to normal.

                SC SVN revision 6783, fresh rebuild
                OpenSuse, KDE 4.3.1

                ---------------------------------------------------------------------
                To unsubscribe, e-mail:
                dev-unsubscribe@sip-communicator.dev.java.net
                <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
                For additional commands, e-mail:
                dev-help@sip-communicator.dev.java.net
                <mailto:dev-help@sip-communicator.dev.java.net>

            ---------------------------------------------------------------------
            To unsubscribe, e-mail:
            dev-unsubscribe@sip-communicator.dev.java.net
            <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
            For additional commands, e-mail:
            dev-help@sip-communicator.dev.java.net
            <mailto:dev-help@sip-communicator.dev.java.net>

        ---------------------------------------------------------------------
        To unsubscribe, e-mail:
        dev-unsubscribe@sip-communicator.dev.java.net
        <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
        For additional commands, e-mail:
        dev-help@sip-communicator.dev.java.net
        <mailto:dev-help@sip-communicator.dev.java.net>

    ---------------------------------------------------------------------
    To unsubscribe, e-mail:
    dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    For additional commands, e-mail:
    dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#9

Hi all,

the "heavy-weight" patch works, thanks.

Regarding the "slowness" when showing the preview window:

- I've checked that XSHM works, and it does.
- Regarding CPU load: it's not SC, but the Xorg server that
  uses about 98% of one of my 2 CPUs, SC is around ~5% on the
  other CPU - lucky me that I have a dual core CPU :slight_smile:

Seb, how often do you call the screencapture per second? Is this
adjustable (or, just for first tests: where is it specified?)

Regards,
Werner

PS:
Maybe the slow reaction is somehow caused by my "small" screen of
just 1600x1200 pixels :wink: --
thus we deal with ~4MB per screenshot.

Werner

···

Am 23.02.2010 17:32, schrieb Sebastien Vincent:

Damian Minkov a �crit :

Hi Seb,

I tested at my side and it works ok on my Linux machine.

I tested on Windows 32-bit and Mac OS X 10.5 (Leopard) 32-bit and it is
working fine. I will commit after a final test on Windows x64.
--
Seb

Cheers
damencho

On Tue, Feb 23, 2010 at 4:07 PM, Sebastien Vincent >> <seb@sip-communicator.org <mailto:seb@sip-communicator.org>> wrote:

    Werner Dittmann a �crit :

        Seb, see inline

        Am 22.02.2010 08:30, schrieb Sebastien Vincent:
        
            Hi Werner,

            On my desktop I can choose "No device" in the list but
            maybe item is
            masked by the current video preview (Java
            heavyweight/lightweight
            Component mix). Try to play with "down" arrow to select
            other choices
            (No device or other video capture device).
              
        Thanks, playing with arrow keys work, but it is inconvenient
        :-) because
        no optical feedback
        
    We can disable "lightweight" property of a JComboBox with the
    patch attached. Tell me if it works for you.
    I think it is safe to commit after if it works.

    Regards,
    --
    Seb

            For the desktop streaming slowdown I think it is related
            to your Xorg
            driver that do not support X Shared Memory extensions
            (XSHM). What
            graphics card/driver do you use ?
              
        I've a fairly new ATI 4650 and I use the proprietary ATI fglrx
        driver.
        I used Mplayer to check if the x11 drivers worka. The follwing
        mplayer
        video out drivers work on my system:

        mplayer -vo x11 file.avi
        mplayer -vo xv file.avi
        mplayer -vo gl file.avi
        mplayer -vo gl2 file.avi

        The first driver (x11) uses shared memory according to mplayer
        documentation.
        Do I need to configure something in SC?

        When using SC and selecting the media configuration and have
        the desktop
        preview then SC currently uses ~2GB of main memnory and nearly
        all CPU cycles.

        Regards,
        Werner

<SNIP --- SNAP>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#10

Werner Dittmann a �crit :

Hi all,

the "heavy-weight" patch works, thanks.

Regarding the "slowness" when showing the preview window:

- I've checked that XSHM works, and it does.
- Regarding CPU load: it's not SC, but the Xorg server that
  uses about 98% of one of my 2 CPUs, SC is around ~5% on the
  other CPU - lucky me that I have a dual core CPU :slight_smile:

Seb, how often do you call the screencapture per second? Is this
adjustable (or, just for first tests: where is it specified?)
  
DataSource try to capture each 100 ms and for the moment it is not adjustable (except by hardcode another value). It is located in src/net/java/sip/communicator/impl/neomedia/jmfext/media/protocol/imgstreaming/ImageStream.java in function read(Buffer buffer) => maxTime.

Regards,
Werner

PS:
Maybe the slow reaction is somehow caused by my "small" screen of
just 1600x1200 pixels :wink: --
thus we deal with ~4MB per screenshot.
  
Personnally I test on 1280x1024 and 1280x800 screen but very soon I will be able to test on a 1900x1200 screen and I can give feedback between "small" and "big" screen with desktop streaming use.

Is there anyone else who test desktop streaming and feel the desktop interaction slow when enabled ?

Regards,

···

--
Seb

Werner

Am 23.02.2010 17:32, schrieb Sebastien Vincent:
  

Damian Minkov a �crit :
    

Hi Seb,

I tested at my side and it works ok on my Linux machine.
      

I tested on Windows 32-bit and Mac OS X 10.5 (Leopard) 32-bit and it is
working fine. I will commit after a final test on Windows x64.
--
Seb

Cheers
damencho

On Tue, Feb 23, 2010 at 4:07 PM, Sebastien Vincent >>> <seb@sip-communicator.org <mailto:seb@sip-communicator.org>> wrote:

    Werner Dittmann a �crit :

        Seb, see inline

        Am 22.02.2010 08:30, schrieb Sebastien Vincent:
                    Hi Werner,

            On my desktop I can choose "No device" in the list but
            maybe item is
            masked by the current video preview (Java
            heavyweight/lightweight
            Component mix). Try to play with "down" arrow to select
            other choices
            (No device or other video capture device).
                      Thanks, playing with arrow keys work, but it is inconvenient
        :-) because
        no optical feedback
        
    We can disable "lightweight" property of a JComboBox with the
    patch attached. Tell me if it works for you.
    I think it is safe to commit after if it works.

    Regards,
    --
    Seb

                    For the desktop streaming slowdown I think it is related
            to your Xorg
            driver that do not support X Shared Memory extensions
            (XSHM). What
            graphics card/driver do you use ?
                      I've a fairly new ATI 4650 and I use the proprietary ATI fglrx
        driver.
        I used Mplayer to check if the x11 drivers worka. The follwing
        mplayer
        video out drivers work on my system:

        mplayer -vo x11 file.avi
        mplayer -vo xv file.avi
        mplayer -vo gl file.avi
        mplayer -vo gl2 file.avi

        The first driver (x11) uses shared memory according to mplayer
        documentation.
        Do I need to configure something in SC?

        When using SC and selecting the media configuration and have
        the desktop
        preview then SC currently uses ~2GB of main memnory and nearly
        all CPU cycles.

        Regards,
        Werner

<SNIP --- SNAP>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#11

Is there anyone else who test desktop streaming and feel the desktop

interaction slow when enabled ?

When I replaced you in the desktop streaming FOSDEM 2010 demonstration, both I and Damencho thought that the interaction with my desktop has become noticeably slower: Totem which I used to play the Big Buck Bunny MKV started playing sluggishly, starting other applications began taking roughly twice the time...

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#12

I know this is not really a question that suits this forum, but I am really lost here. I am using Eclipse and I have checked-out the sip-communicator, but I have issues with the project. For example the src folder does not appear as a src folder, but just as any other folder. I copied the .project and the other one as explained on the website.

Can someone help me with it? Tx, Matthijs

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#13

All,

to get some more data on this I made some measurements and came to
some interesting result:

- the whole readScreen(...) in the ImageStream class takes ~1.5s
  on average on my system. No way to come down to 100ms.

- the main time consumer is the XShmGetImage(...) function in the
  C JNI module. This functions consumes about 90% (or slightly more)
  of the overall time. During this ~1.5s the screen "freezes" as if
  the XShmGetImage(...) function blocks all other activities. During
  that time you can't move a window, no mouse click goes to a window
  etc.

I've also tested with SHM switched off and the result is nearly the
same on my system - which is strange. I suspected that SHM is faster
than the other method. Here I try to give some explanations:

- SHM does not work but the SHM functions just work as if SHM is working
  (well, this I don't believe, to be honest)
- the non SHM functions internally map to SHM functions and work with
  SHM "under the hood" - which could be the case.
- any other explanations ???

Please keep in mind that I have a 1600x1200 screen and the X server must
copy about 8MB into the shared memory segment.

I'll do some more investigations to see if we can speed up the
screen capture.

Regards,
Werner

···

Am 24.02.2010 12:32, schrieb Lubomir Marinov:

Is there anyone else who test desktop streaming and feel the desktop

interaction slow when enabled ?

When I replaced you in the desktop streaming FOSDEM 2010 demonstration,
both I and Damencho thought that the interaction with my desktop has
become noticeably slower: Totem which I used to play the Big Buck Bunny
MKV started playing sluggishly, starting other applications began taking
roughly twice the time...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#14

I followed the instructions for setting up the SIP Communicator project into Eclipse yesterday and they worked for me like a charm. My advice to you is to try again. In a nutshell, check out the project with whatever tool you feel comfortable with (be it Eclipse or the command-line svn client), copy .project and .classpath (that's where the source folders are specified) from ide/eclipse into the root of the dev tree and open/import the project into Eclipse.

···

On 02/24/2010 04:42 PM, Matthijs Dinant wrote:

I know this is not really a question that suits this forum, but I am really lost here. I am using Eclipse and I have checked-out the sip-communicator, but I have issues with the project. For example the src folder does not appear as a src folder, but just as any other folder. I copied the .project and the other one as explained on the website.

Can someone help me with it? Tx, Matthijs

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#15

Hi Werner,

Werner Dittmann a �crit :

All,

to get some more data on this I made some measurements and came to
some interesting result:

- the whole readScreen(...) in the ImageStream class takes ~1.5s
  on average on my system. No way to come down to 100ms.

- the main time consumer is the XShmGetImage(...) function in the
  C JNI module. This functions consumes about 90% (or slightly more)
  of the overall time. During this ~1.5s the screen "freezes" as if
  the XShmGetImage(...) function blocks all other activities. During
  that time you can't move a window, no mouse click goes to a window
  etc.

I've also tested with SHM switched off and the result is nearly the
same on my system - which is strange. I suspected that SHM is faster
than the other method. Here I try to give some explanations:

- SHM does not work but the SHM functions just work as if SHM is working
  (well, this I don't believe, to be honest)
- the non SHM functions internally map to SHM functions and work with
  SHM "under the hood" - which could be the case.
- any other explanations ???

Please keep in mind that I have a 1600x1200 screen and the X server must
copy about 8MB into the shared memory segment.

Wow 1,5 seconds per capture is a lot! But as I say I have not tested on big display.

Can you test with opensource ATI driver to see if it is not the fglrx driver fault ? (I doubt but maybe...)

I'll do some more investigations to see if we can speed up the
screen capture.
  
OK.

Regards,

···

--
Seb

Regards,
Werner

Am 24.02.2010 12:32, schrieb Lubomir Marinov:
  

Is there anyone else who test desktop streaming and feel the desktop
      

interaction slow when enabled ?

When I replaced you in the desktop streaming FOSDEM 2010 demonstration,
both I and Damencho thought that the interaction with my desktop has
become noticeably slower: Totem which I used to play the Big Buck Bunny
MKV started playing sluggishly, starting other applications began taking
roughly twice the time...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#16

Tx Lubomir, I had to use the wizard for it to work, I also had to dload the org.osgi.framework, but anyway, it works

···

-----Original Message-----

From: Lubomir Marinov [mailto:lubo@sip-communicator.org]

Sent: Wednesday, February 24, 2010 3:48 PM
To: dev@sip-communicator.dev.java.net
Cc: IPCO_MAIL
Subject: Re: [sip-comm-dev] eclipse

I followed the instructions for setting up the SIP Communicator project
into Eclipse yesterday and they worked for me like a charm. My advice to
you is to try again. In a nutshell, check out the project with whatever
tool you feel comfortable with (be it Eclipse or the command-line svn
client), copy .project and .classpath (that's where the source folders
are specified) from ide/eclipse into the root of the dev tree and
open/import the project into Eclipse.

On 02/24/2010 04:42 PM, Matthijs Dinant wrote:

I know this is not really a question that suits this forum, but I am really lost here. I am using Eclipse and I have checked-out the sip-communicator, but I have issues with the project. For example the src folder does not appear as a src folder, but just as any other folder. I copied the .project and the other one as explained on the website.

Can someone help me with it? Tx, Matthijs

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#17

Hi Seb,

looking around a little bit I saw some other messages (not many, just
a few) that complain about this. The reason could be that on most
high level grafic cards the screen data is stored inside the card, not
in the main memory of the CPU. Thus the X server has to fetch the
data from the card, maybe even converting it into a specific format
and copying it into the shared memory.

Also the Xserver blocks video activity during this copy process to
avoid copying wrong data ("disturbed" screen data between to screen
refresh/update cycles).

I will check some more details :slight_smile: .

Regards,
Werner

···

Am 25.02.2010 17:29, schrieb Sebastien Vincent:

Hi Werner,

Werner Dittmann a �crit :

All,

to get some more data on this I made some measurements and came to
some interesting result:

- the whole readScreen(...) in the ImageStream class takes ~1.5s
  on average on my system. No way to come down to 100ms.

- the main time consumer is the XShmGetImage(...) function in the
  C JNI module. This functions consumes about 90% (or slightly more)
  of the overall time. During this ~1.5s the screen "freezes" as if
  the XShmGetImage(...) function blocks all other activities. During
  that time you can't move a window, no mouse click goes to a window
  etc.

I've also tested with SHM switched off and the result is nearly the
same on my system - which is strange. I suspected that SHM is faster
than the other method. Here I try to give some explanations:

- SHM does not work but the SHM functions just work as if SHM is working
  (well, this I don't believe, to be honest)
- the non SHM functions internally map to SHM functions and work with
  SHM "under the hood" - which could be the case.
- any other explanations ???

Please keep in mind that I have a 1600x1200 screen and the X server must
copy about 8MB into the shared memory segment.

Wow 1,5 seconds per capture is a lot! But as I say I have not tested on
big display.

Can you test with opensource ATI driver to see if it is not the fglrx
driver fault ? (I doubt but maybe...)

I'll do some more investigations to see if we can speed up the
screen capture.
  
OK.

Regards,
--
Seb

Regards,
Werner

Am 24.02.2010 12:32, schrieb Lubomir Marinov:

Is there anyone else who test desktop streaming and feel the desktop
      

interaction slow when enabled ?

When I replaced you in the desktop streaming FOSDEM 2010 demonstration,
both I and Damencho thought that the interaction with my desktop has
become noticeably slower: Totem which I used to play the Big Buck Bunny
MKV started playing sluggishly, starting other applications began taking
roughly twice the time...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#18

Hi Werner,

Now I have my new 1920X1200 screen, I can tell you that in preview with desktop streaming... I see no changes compared to my 1280x1024 screen, no slowdown (I have a Nvidia GeForce 8600 GTS). So yes it could be related to what you said for the "high level graphics cards".

Regards,

···

--
Seb

Werner Dittmann a �crit :

Hi Seb,

looking around a little bit I saw some other messages (not many, just
a few) that complain about this. The reason could be that on most
high level grafic cards the screen data is stored inside the card, not
in the main memory of the CPU. Thus the X server has to fetch the
data from the card, maybe even converting it into a specific format
and copying it into the shared memory.

Also the Xserver blocks video activity during this copy process to
avoid copying wrong data ("disturbed" screen data between to screen
refresh/update cycles).

I will check some more details :slight_smile: .

Regards,
Werner

Am 25.02.2010 17:29, schrieb Sebastien Vincent:
  

Hi Werner,

Werner Dittmann a �crit :
    

All,

to get some more data on this I made some measurements and came to
some interesting result:

- the whole readScreen(...) in the ImageStream class takes ~1.5s
  on average on my system. No way to come down to 100ms.

- the main time consumer is the XShmGetImage(...) function in the
  C JNI module. This functions consumes about 90% (or slightly more)
  of the overall time. During this ~1.5s the screen "freezes" as if
  the XShmGetImage(...) function blocks all other activities. During
  that time you can't move a window, no mouse click goes to a window
  etc.

I've also tested with SHM switched off and the result is nearly the
same on my system - which is strange. I suspected that SHM is faster
than the other method. Here I try to give some explanations:

- SHM does not work but the SHM functions just work as if SHM is working
  (well, this I don't believe, to be honest)
- the non SHM functions internally map to SHM functions and work with
  SHM "under the hood" - which could be the case.
- any other explanations ???

Please keep in mind that I have a 1600x1200 screen and the X server must
copy about 8MB into the shared memory segment.

Wow 1,5 seconds per capture is a lot! But as I say I have not tested on
big display.

Can you test with opensource ATI driver to see if it is not the fglrx
driver fault ? (I doubt but maybe...)

I'll do some more investigations to see if we can speed up the
screen capture.
  

OK.

Regards,
--
Seb

Regards,
Werner

Am 24.02.2010 12:32, schrieb Lubomir Marinov:

Is there anyone else who test desktop streaming and feel the desktop
      

interaction slow when enabled ?

When I replaced you in the desktop streaming FOSDEM 2010 demonstration,
both I and Damencho thought that the interaction with my desktop has
become noticeably slower: Totem which I used to play the Big Buck Bunny
MKV started playing sluggishly, starting other applications began taking
roughly twice the time...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#19

Hi Seb,

IMHO the problem is really based on the graphic card. I've found
a note at the x11vnc site stating:

<quote>
A rate limiting factor for x11vnc performance is that graphics hardware
is optimized for writing, not reading (x11vnc reads the video framebuffer
for the screen image data.) The difference can be a factor of 10 to 1000,
and so it usually takes about 0.5-1 sec to read in the whole video hardware
framebuffer (e.g. 5MB for 1280x1024 at depth 24 with a read rate
of 5-10MB/sec.) So whenever activity changes most of the screen
(e.g. moving or iconifying a large window) there is a delay of 0.5-1 sec
while x11vnc reads the changed regions in.
</qoute>

The article also states some tools to measure the performance. I did
this and here are the results for the "read image data":

werner@linux-black:~> x11perf -getimage500
x11perf - X11 performance program, version 1.2
The X.Org Foundation server version 10605000 on :0.0
from linux-black
Mon Mar 1 17:22:04 2010

Sync time adjustment is 0.0531 msecs.

     32 reps @ 162.8043 msec ( 6.1/sec): GetImage 500x500 square
     32 reps @ 163.2362 msec ( 6.1/sec): GetImage 500x500 square
     32 reps @ 162.7332 msec ( 6.2/sec): GetImage 500x500 square
     32 reps @ 162.7246 msec ( 6.2/sec): GetImage 500x500 square
     32 reps @ 162.8290 msec ( 6.1/sec): GetImage 500x500 square
    160 trep @ 162.8654 msec ( 6.1/sec): GetImage 500x500 square

Applying this to a 1600x1200 screen we have to multiply the 162.8 ms by
a factor of 7.84 (1600:500=3.2; 1200:500=2.4; 3.2*2.4=7.68) and this gives
a result of ~1250ms. I also did a simple test with dd:

werner@linux-black:~> dd if=/dev/fb0 of=/dev/null
15000+0 Datens�tze ein
15000+0 Datens�tze aus
7680000 Bytes (7,7 MB) kopiert, 1,25261 s, 6,1 MB/s

dd reads the whole framebuffer and writes it to /dev/null, similar result.

Here the link to the x11vnc page:

<http://www.karlrunge.com/x11vnc/>

Just as additional info: using x11perf to write a 500x500 window results in
144 writes per second, writing via shared memory gives me 388 writes per second.
Compare this with 6.1 reads per second above. According to my tests there is no
real difference between "normal" getImage and shmGetImage because the limiting
factor seems to be the graphic card and not the transfer between X server
and application (which is consistent with the observations :slight_smile: ).

Also there are differences between Nvidia cards and AMD/ATI cards. The X11vnc
article states, that the proprietary nvidia graphic driver supports faster
read since some time. Seems that this is not true for AMD/ATI cards (my card
is about 1yr old).

Regards,
Werner

···

Am 01.03.2010 09:31, schrieb Sebastien Vincent:

Hi Werner,

Now I have my new 1920X1200 screen, I can tell you that in preview with
desktop streaming... I see no changes compared to my 1280x1024 screen,
no slowdown (I have a Nvidia GeForce 8600 GTS). So yes it could be
related to what you said for the "high level graphics cards".

Regards,
--
Seb

Werner Dittmann a �crit :

Hi Seb,

looking around a little bit I saw some other messages (not many, just
a few) that complain about this. The reason could be that on most
high level grafic cards the screen data is stored inside the card, not
in the main memory of the CPU. Thus the X server has to fetch the
data from the card, maybe even converting it into a specific format
and copying it into the shared memory.

Also the Xserver blocks video activity during this copy process to
avoid copying wrong data ("disturbed" screen data between to screen
refresh/update cycles).

I will check some more details :slight_smile: .

Regards,
Werner

Am 25.02.2010 17:29, schrieb Sebastien Vincent:

Hi Werner,

Werner Dittmann a �crit :
   

All,

to get some more data on this I made some measurements and came to
some interesting result:

- the whole readScreen(...) in the ImageStream class takes ~1.5s
  on average on my system. No way to come down to 100ms.

- the main time consumer is the XShmGetImage(...) function in the
  C JNI module. This functions consumes about 90% (or slightly more)
  of the overall time. During this ~1.5s the screen "freezes" as if
  the XShmGetImage(...) function blocks all other activities. During
  that time you can't move a window, no mouse click goes to a window
  etc.

I've also tested with SHM switched off and the result is nearly the
same on my system - which is strange. I suspected that SHM is faster
than the other method. Here I try to give some explanations:

- SHM does not work but the SHM functions just work as if SHM is
working
  (well, this I don't believe, to be honest)
- the non SHM functions internally map to SHM functions and work with
  SHM "under the hood" - which could be the case.
- any other explanations ???

Please keep in mind that I have a 1600x1200 screen and the X server
must
copy about 8MB into the shared memory segment.

Wow 1,5 seconds per capture is a lot! But as I say I have not tested on
big display.

Can you test with opensource ATI driver to see if it is not the fglrx
driver fault ? (I doubt but maybe...)

I'll do some more investigations to see if we can speed up the
screen capture.
        

OK.

Regards,
--
Seb

Regards,
Werner

Am 24.02.2010 12:32, schrieb Lubomir Marinov:

Is there anyone else who test desktop streaming and feel the desktop
                

interaction slow when enabled ?

When I replaced you in the desktop streaming FOSDEM 2010
demonstration,
both I and Damencho thought that the interaction with my desktop has
become noticeably slower: Totem which I used to play the Big Buck
Bunny
MKV started playing sluggishly, starting other applications began
taking
roughly twice the time...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#20

Hi Werner,

Thanks for the explanations.

···

--
Seb

Werner Dittmann a �crit :

Hi Seb,

IMHO the problem is really based on the graphic card. I've found
a note at the x11vnc site stating:

<quote>
A rate limiting factor for x11vnc performance is that graphics hardware
is optimized for writing, not reading (x11vnc reads the video framebuffer
for the screen image data.) The difference can be a factor of 10 to 1000,
and so it usually takes about 0.5-1 sec to read in the whole video hardware
framebuffer (e.g. 5MB for 1280x1024 at depth 24 with a read rate
of 5-10MB/sec.) So whenever activity changes most of the screen
(e.g. moving or iconifying a large window) there is a delay of 0.5-1 sec
while x11vnc reads the changed regions in.
</qoute>

The article also states some tools to measure the performance. I did
this and here are the results for the "read image data":

werner@linux-black:~> x11perf -getimage500
x11perf - X11 performance program, version 1.2
The X.Org Foundation server version 10605000 on :0.0
from linux-black
Mon Mar 1 17:22:04 2010

Sync time adjustment is 0.0531 msecs.

     32 reps @ 162.8043 msec ( 6.1/sec): GetImage 500x500 square
     32 reps @ 163.2362 msec ( 6.1/sec): GetImage 500x500 square
     32 reps @ 162.7332 msec ( 6.2/sec): GetImage 500x500 square
     32 reps @ 162.7246 msec ( 6.2/sec): GetImage 500x500 square
     32 reps @ 162.8290 msec ( 6.1/sec): GetImage 500x500 square
    160 trep @ 162.8654 msec ( 6.1/sec): GetImage 500x500 square

Applying this to a 1600x1200 screen we have to multiply the 162.8 ms by
a factor of 7.84 (1600:500=3.2; 1200:500=2.4; 3.2*2.4=7.68) and this gives
a result of ~1250ms. I also did a simple test with dd:

werner@linux-black:~> dd if=/dev/fb0 of=/dev/null
15000+0 Datens�tze ein
15000+0 Datens�tze aus
7680000 Bytes (7,7 MB) kopiert, 1,25261 s, 6,1 MB/s

dd reads the whole framebuffer and writes it to /dev/null, similar result.

Here the link to the x11vnc page:

<http://www.karlrunge.com/x11vnc/>

Just as additional info: using x11perf to write a 500x500 window results in
144 writes per second, writing via shared memory gives me 388 writes per second.
Compare this with 6.1 reads per second above. According to my tests there is no
real difference between "normal" getImage and shmGetImage because the limiting
factor seems to be the graphic card and not the transfer between X server
and application (which is consistent with the observations :slight_smile: ).

Also there are differences between Nvidia cards and AMD/ATI cards. The X11vnc
article states, that the proprietary nvidia graphic driver supports faster
read since some time. Seems that this is not true for AMD/ATI cards (my card
is about 1yr old).

Regards,
Werner

Am 01.03.2010 09:31, schrieb Sebastien Vincent:
  

Hi Werner,

Now I have my new 1920X1200 screen, I can tell you that in preview with
desktop streaming... I see no changes compared to my 1280x1024 screen,
no slowdown (I have a Nvidia GeForce 8600 GTS). So yes it could be
related to what you said for the "high level graphics cards".

Regards,
--
Seb

Werner Dittmann a �crit :
    

Hi Seb,

looking around a little bit I saw some other messages (not many, just
a few) that complain about this. The reason could be that on most
high level grafic cards the screen data is stored inside the card, not
in the main memory of the CPU. Thus the X server has to fetch the
data from the card, maybe even converting it into a specific format
and copying it into the shared memory.

Also the Xserver blocks video activity during this copy process to
avoid copying wrong data ("disturbed" screen data between to screen
refresh/update cycles).

I will check some more details :slight_smile: .

Regards,
Werner

Am 25.02.2010 17:29, schrieb Sebastien Vincent:

Hi Werner,

Werner Dittmann a �crit :
   

All,

to get some more data on this I made some measurements and came to
some interesting result:

- the whole readScreen(...) in the ImageStream class takes ~1.5s
  on average on my system. No way to come down to 100ms.

- the main time consumer is the XShmGetImage(...) function in the
  C JNI module. This functions consumes about 90% (or slightly more)
  of the overall time. During this ~1.5s the screen "freezes" as if
  the XShmGetImage(...) function blocks all other activities. During
  that time you can't move a window, no mouse click goes to a window
  etc.

I've also tested with SHM switched off and the result is nearly the
same on my system - which is strange. I suspected that SHM is faster
than the other method. Here I try to give some explanations:

- SHM does not work but the SHM functions just work as if SHM is
working
  (well, this I don't believe, to be honest)
- the non SHM functions internally map to SHM functions and work with
  SHM "under the hood" - which could be the case.
- any other explanations ???

Please keep in mind that I have a 1600x1200 screen and the X server
must
copy about 8MB into the shared memory segment.

Wow 1,5 seconds per capture is a lot! But as I say I have not tested on
big display.

Can you test with opensource ATI driver to see if it is not the fglrx
driver fault ? (I doubt but maybe...)

I'll do some more investigations to see if we can speed up the
screen capture.
        

OK.

Regards,
--
Seb

Regards,
Werner

Am 24.02.2010 12:32, schrieb Lubomir Marinov:

Is there anyone else who test desktop streaming and feel the desktop
                

interaction slow when enabled ?

When I replaced you in the desktop streaming FOSDEM 2010
demonstration,
both I and Damencho thought that the interaction with my desktop has
become noticeably slower: Totem which I used to play the Big Buck
Bunny
MKV started playing sluggishly, starting other applications began
taking
roughly twice the time...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net