>> Are there any other tools I should be aware of, or inbound patch sets
>> that would change things significantly?
>
> Soren is working on RENDER support. He showed benchmarks that suggest
> it would be a significant improvement.
>
> http://lists.freedesktop.org/archives/spice-devel/2012-May/00
On Fri, Jun 29, 2012 at 11:37:37AM -0500, Jeremy White wrote:
> I am going to dive into the xf86 driver performance in a serious way
> starting next week.
>
> I'm planning on building instrumentation to let me build sample data
> sets. I want to see what sort of X operations result from a typical
- Original Message -
> I am going to dive into the xf86 driver performance in a serious way
> starting next week.
This is great news - good luck!
>
> I'm planning on building instrumentation to let me build sample data
> sets. I want to see what sort of X operations result from a typica
I am going to dive into the xf86 driver performance in a serious way
starting next week.
I'm planning on building instrumentation to let me build sample data
sets. I want to see what sort of X operations result from a typical
work load, and how the pipes fill up, so I can start to try to find
pat
On Mon, 2012-05-28 at 12:59 +0300, Alon Levy wrote:
> On Mon, May 28, 2012 at 11:29:23AM +0200, Attila Sukosd wrote:
> > Low latency (and relatively low bandwidth) video streaming can be done with
> > x264 and xvid (low enough for a 3d game to be playable over the net)
> > However, it introduces li
On Mon, 2012-05-28 at 12:59 +0300, Alon Levy wrote:
> On Mon, May 28, 2012 at 11:29:23AM +0200, Attila Sukosd wrote:
> > Low latency (and relatively low bandwidth) video streaming can be done with
> > x264 and xvid (low enough for a 3d game to be playable over the net)
> > However, it introduces li
On Mon, May 28, 2012 at 12:19:57PM +0300, Alon Levy wrote:
> On Thu, May 24, 2012 at 01:24:05PM -0500, Jeremy White wrote:
> > > Actually, for WAN, we require ACK for 40 messages, but we allow sending
> > > up to 80, without getting an ack for the first 40.
> > > From my experience with Windows gue
>> Is that todo on anyone’s immediate radar? I'm certainly not qualified,
>> but it seems like that could have an major impact on what we're trying
>> to achieve (regular Office applications hosted on a pure Linux server
>> across a WAN). So perhaps I need to become qualified :-/.
>
> I have a p
On Mon, May 28, 2012 at 11:29:23AM +0200, Attila Sukosd wrote:
> Low latency (and relatively low bandwidth) video streaming can be done with
> x264 and xvid (low enough for a 3d game to be playable over the net)
> However, it introduces licensing issues and high-ish CPU usage on the host
> side :(
Low latency (and relatively low bandwidth) video streaming can be done with
x264 and xvid (low enough for a 3d game to be playable over the net)
However, it introduces licensing issues and high-ish CPU usage on the host
side :(
On Mon, May 28, 2012 at 11:19 AM, Alon Levy wrote:
> On Thu, May 24
On Fri, May 25, 2012 at 09:07:43AM +0200, Alexander Larsson wrote:
> On Wed, 2012-05-23 at 15:20 -0500, Jeremy White wrote:
>
> > Also, as a crazy idea, has anyone considered implementing a pure
> > streaming video driver? That is, what if we had a frame buffer driver,
> > and then a thread that
On Thu, May 24, 2012 at 01:24:05PM -0500, Jeremy White wrote:
> > Actually, for WAN, we require ACK for 40 messages, but we allow sending
> > up to 80, without getting an ack for the first 40.
> > From my experience with Windows guest, it sounds like the DRAW_FILL
> > commands might be related to a
Alexander Larsson píše v Pá 25. 05. 2012 v 09:07 +0200:
> On Wed, 2012-05-23 at 15:20 -0500, Jeremy White wrote:
>
> > Also, as a crazy idea, has anyone considered implementing a pure
> > streaming video driver? That is, what if we had a frame buffer driver,
> > and then a thread that fired 29 ti
On Wed, 2012-05-23 at 15:20 -0500, Jeremy White wrote:
> Also, as a crazy idea, has anyone considered implementing a pure
> streaming video driver? That is, what if we had a frame buffer driver,
> and then a thread that fired 29 times a second to drive a theora or vp8
> encoder, simply feeding th
On Thu, 2012-05-24 at 20:38 +0300, Yonit Halperin wrote:
> What OS your client has? When spice-server identifies WAN, it
> automatically turn on Nagle's for the display channel (turns off
> TCP_NODELAY), which should aggregate small tcp messages. However, it has
> bad interaction with the delaye
> Actually, for WAN, we require ACK for 40 messages, but we allow sending
> up to 80, without getting an ack for the first 40.
> From my experience with Windows guest, it sounds like the DRAW_FILL
> commands might be related to anti aliasing, and maybe the future RENDER
> support that Alon mentione
On 05/24/2012 05:30 PM, Jeremy White wrote:
No, what we do is combine some operations (change/drop) by looking at
current outstanding messages (queued but not yet sent - in the pipe)
whenever we read a new message from the device (from the ring). There is
a good visual iirc on spice-space.org .
Hi,
On 05/24/2012 05:30 PM, Jeremy White wrote:
No, what we do is combine some operations (change/drop) by looking at
current outstanding messages (queued but not yet sent - in the pipe)
whenever we read a new message from the device (from the ring). There is
a good visual iirc on spice-space.org
> No, what we do is combine some operations (change/drop) by looking at
> current outstanding messages (queued but not yet sent - in the pipe)
> whenever we read a new message from the device (from the ring). There is
> a good visual iirc on spice-space.org .
I didn't find a visual that address th
> There is certainly room for experimentation, improvements and tweaking!
Thanks for the input on the video concept.
If I get time, I may do some experimentation with different video
codecs. I may be out of luck, though, as I need to limit myself to
codecs that are supported by the html5 standar
Jeremy White wrote:
I need to improve the performance of the xf86-video-qxl driver; aka
xspice; by a fairly substantial margin.
I've set up a test case - LibreOffice over an 80 ms latency connection -
that demonstrates that it's got quite a long way to go. (The current
case appears to suffer fr
On Thu, 2012-05-24 at 07:28 -0400, Yaniv Kaul wrote:
> - Original Message -
> > I need to improve the performance of the xf86-video-qxl driver; aka
> > xspice; by a fairly substantial margin.
>
> What performance characteristic would you like to improve?
> 1. Performance over WAN (high lat
- Original Message -
> I need to improve the performance of the xf86-video-qxl driver; aka
> xspice; by a fairly substantial margin.
What performance characteristic would you like to improve?
1. Performance over WAN (high latency and/or low bandwidth) ?
2. CPU usage (on the server and/or t
On Thu, May 24, 2012 at 9:35 AM, Alon Levy wrote:
> This one looks interesting:
> http://lags.leetcode.net/codec.html
>
> I also don't know vp8 enough, maybe it's possible to use it as
> lossless? Also like Marc-Andre said, compression speed is a major issue.
A general lossless video codec is not
On Wed, May 23, 2012 at 03:20:21PM -0500, Jeremy White wrote:
> I need to improve the performance of the xf86-video-qxl driver; aka
> xspice; by a fairly substantial margin.
>
> I've set up a test case - LibreOffice over an 80 ms latency connection -
> that demonstrates that it's got quite a long
On Wed, May 23, 2012 at 10:02:03PM -0400, Marc-André Lureau wrote:
> Hi
>
> - Mensaje original -
> > Also, as a crazy idea, has anyone considered implementing a pure
> > streaming video driver? That is, what if we had a frame buffer
> > driver,
> > and then a thread that fired 29 times a
On Wed, May 23, 2012 at 03:20:21PM -0500, Jeremy White wrote:
> I need to improve the performance of the xf86-video-qxl driver; aka
> xspice; by a fairly substantial margin.
>
> I've set up a test case - LibreOffice over an 80 ms latency connection -
> that demonstrates that it's got quite a long
Hi
- Mensaje original -
> Also, as a crazy idea, has anyone considered implementing a pure
> streaming video driver? That is, what if we had a frame buffer
> driver,
> and then a thread that fired 29 times a second to drive a theora or
> vp8
> encoder, simply feeding the current frame at
I need to improve the performance of the xf86-video-qxl driver; aka
xspice; by a fairly substantial margin.
I've set up a test case - LibreOffice over an 80 ms latency connection -
that demonstrates that it's got quite a long way to go. (The current
case appears to suffer from an excessive set of
29 matches
Mail list logo
