Better Client-side compression for faster response times RRS feed

  • General discussion

  • I have noticed that there are many compaints about 'lagginess'. I believe this is mainly caused by an inefficient compression codec that SharedView uses to send screenshots to the other users. Reportedly, this problem appears especially with large screen updates.

    I don't know which technology is being used to send the data etc., but I would like to suggest the following features:
    Better compression for slower connections, using:
    - Perhaps a video codec for initial screen updates? (as an overlay until more Accurate data can be read)
    - Smarter screen capture? (Some shared applications had only a few draws, but they must have caused an entire window caputer because they were so far apart)
    - Does this make use of the Terminal Services protocol? If so, why not enable Bitmap Caching?
    - In comparison to the first bullet, maybe implement an automatic quality downgrade of updating screen sections which increase until the picture matches? (think: some pictures used to download in internet explorer first as a box of colored (large) pixels, which (as the download continued) divided and divided until the picture was complete, first showing a general idea of the finished product and then clarifying until done, although by "speeding" up the interaction it may become annoying to some)

    Is there a way to use a video codec to grab the screen updates? In my oppinion, if this would be possible and acceptable, it would save both bandwidth and lagg.
    Thursday, January 31, 2008 3:58 AM

All replies

  • Hello Tsaukpaetra,

    Thank you for your suggestions and thanks for using SharedView.

    Thursday, January 31, 2008 5:14 PM