Older blog entries for const (starting at number 6)

[Work]

Worked hard on the VNC compression project. First result is that subset of new "tight" encoding has been implemented in the vncviewer and in a standalone VNC proxy. Currently compression is equivalent to pure zlib encoding as implemented in the TridiaVNC (by the way, I was mistaken saying that zlib compression is implemented inefficiently in the TridiaVNC).

Now it's time to actually improve compression. I see two primary directions to do that:

1. There should be a way to split screen updates into smaller rectangles representing different types of screen data: full-color areas, bi-level drawings, solid areas etc.). Each subrectangle should be compressed in a separate zlib stream and different filters should be applied for each type of data.
2. Efficient filters (predictors) should be designed to handle data types which usualy compose typical screen contents.

And there are other problems with VNC that interfere with good compression: server sends many unnecessary screen updates (even when screen contents is untouched), potentially large updates frequently being split into many small pieces, etc.

[Home]

My girlfriend dislikes the way I work. I sleep huge part of day and I work the whole night. And I'm tired of smoking: it's time to quit.

Worked on the VNC compression project. Finished with the draft version of new encoding. Need to say that the proposed compression scheme is somewhat too flexible: anything can fit in such encoding (including uncompressed data, hextile-encoded data or even uncompressed data expanded with some garbage :-) It's something like meta-encoding. But it's still too far from the final version. And I'm still not able to compare performance as far as it's not implemented...

While designing this encoding, I've tried to make VNC server do most complex work, so the client modifications will be relatively simple, but the server part can be complex enough. I'm afraid that the amount of time for developing this project will be not enough to do everything ideally, so I'll have to cut my huge ambitions and develop something that is easier to implement... And I'll continue the work after finishing the request at the Cosource.com...

To Whizziwig: I have one good book about FoxPro, and I don't need this book (BTW, I hate FoxPro too). But, unfortunately, the book is in russian. :-)

Yesterday I came to sleep at 8am in the morning and woke up at 7pm today. It's terrible -- I'm a night animal.

I've discovered good news in my mailbox today: mgetty-1.1.21-to-28072000 has been released. I've built new RPM packages for KSI Linux and I'm happy to see that it is the first mgetty version for which I do not have to apply patches to make it build and work as desired. Only distribution-specific config.patch is applied. All corrections I have contributed to mgetty/vgetty are in place. So my patch in the article at Advogato is not actual any more.

But there are other problems: I'm tired to fight with mgetty+pppd combination. It seems like I have kernel/pppd/chat/setserial/mgetty conflict. Pppd had worked but I had to run ifup (or ppp-on) twice with a pause between tries. Now I've changed the chat script a little: modem dials from the first attempt, but I'm still not satisfied because I fail to find the precise reason for the problem. Everything worked ok at another machine with the same configuration, and other programs such as minicom (and chat itself executed without pppd) also share the line with mgetty without any problems. Well, I have not time to refine the problem, and anyway I plan to reinstall the system (BlackCat Linux instead of KSI Linux). Let's see...

Another thing I'm tired of: my provider sucks. And any other provider in our town is even worse. Why am I living in Siberia?

It wanted to know how zlib compression is integrated into the TridiaVNC. I've got several files from their source via CVS and now I know. Exactly as expected: their implementation is not very efficient: the context (dictionary) is not being saved between screen updates. Due to this fact it would be easy to outperform their compression ratios.

http://www.hyperreal.org/raves/vrave/ -- I did not expect that people at hyperreal.org are still updating web pages related to vrave/telechat chat server software. I'd like to thank them one more time for the telechat-1.0 source which was the base for my current project. It's great that they had released that code under the BSD-like license.

And I'm glad that hyperreal.org knows about my project although I have not announced it too widely (it's because I plan to change user DB format in the nearest future, and after that it will be a better time to make announcements).

bzip2 is pathologically slow on data which consist mainly from small repeated patterns such as "ababababab..." or "ccccccccccc...". I know that it's a usual behaviour of block-sorting compression algorithms, but there are workarounds to prevent that... I'm finally tired to wait for a whole hour sitting in front of Pentium II to get a 216K archive...