Pavel Fatin

In this article I explain what it takes to implementing high-quality smooth / high-precision scrolling on modern computers and why some systems have it while others don’t. Most of the insights came from my work on implementing “true smooth scrolling” in IntelliJ IDEA.

The article complements my previous article “Typing with pleasure”, just like scrolling naturally complements typing in the day-to-day activity of most computer users. Nowadays, some interfaces are based solely on scrolling! Because scrolling is so ubiquitous, any improvement in its functioning automatically improves the user experience and can boost our productivity big time.

The topic of scrolling seems to fascinate a surprising amount of people — computer forums are filled with questions like “Why does Mac OS X trackpad moves so much better than Windows?” or “Why no smooth scrolling on Linux?” . Despite the pry, the answers usually come down to something like “Mac OS uses magic, just deal with it”, which only makes the issue even more mysterious. However, as the third Clarke’s law says “Any sufficiently advanced technology is indistinguishable from magic” — so no actual magic is required — the proper technology is all that is needed.

Although the article contains a great deal of technical details, I hope that it will be interesting not only to computer programmers, but also to people who wonder how scrolling works under the hood, why we have what we have and how we can make the scrolling better.

Contents

All the code examples are available as a GitHub repository.
Continue reading →

In this article I examine human- and machine aspects of typing latency (“typing lag”) and present experimental data on latency of popular text / code editors. The article is inspired by my work on implementing “zero-latency typing” in IntelliJ IDEA.

Latency recently became a hot topic in computer world — now we have low-latency keyboards, 144 Hz monitors, special technologies to reduce latency (like FreeSync or G-Sync), dedicated communities and whatnot… Sure, a part of the buzz is marketing, however the truth is that low latency became both feasible and desirable.

Apparently, gamers are the first who gain form those advancements. In some areas, like virtual reality latency turned out to be a crucial factor, where even a single millisecond matters. But what about programmers? Do we need “typing with pleasure” to “develop with pleasure”? Let’s find out.

The article is also (independently) translated into Russian.

See also: Scrolling with pleasure.

Contents:

1. Human side
   1.1. Feedback
   1.2. Motor skill
   1.3. Internal model
   1.4. Multisensory integration
   1.5. Effects
2. Machine side
   2.1. Input latency
   2.2. Processing latency
   2.3. Output latency
   2.4. Total latency
3. Editor benchmarks
   3.1. Configuration
   3.2. Methodology
   3.3. Windows
   3.4. Linux
   3.5. VirtualBox
4. Summary
5. Links
   Continue reading →

Typometer is a tool to measure and analyze visual latency of text / code editors.

Editor latency is delay between an input event and a corresponding screen update, in particular case – delay between keystroke and character appearance. While there are many kinds of delays (caret movement, line editing, etc.), typing latency is a major predictor of editor usability.

Check my article Typing with pleasure to learn more about editor latency and its effects on typing performance.

Project source code is available as a GitHub repository.

Download: typometer-1.0.1-bin.zip (0.5 MB)

Java 8 or latter is required to run the program. You can download Java from the official site.
Continue reading →

In this article I enumerate reasons why typical approach to painting in AWT / Swing can result in substantial visual lags, provide examples that demonstrate the problem and propose methods to significantly reduce the drawing latency.

Despite the focus on Java platform, the key ideas can be extended to most modern operation systems and GUI frameworks.

Contents:

1. Problem statement
2. Typical implementation
3. Asynchronous painting
   3.1. Queue delay
   3.2. Request skip
   3.3. Region extension
   3.4. Component reordering
4. Synchronous painting
   4.1. Component opacity
   4.2. Buffering overhead
   4.3. Showing delay
   4.4. Buffer reuse
5. Active rendering
   5.1. Incremental painting
   5.2. Pipeline flush
6. Summary

All key points are accompanied by short, shelf contained, compilable examples that clearly demonstrate the theoretical concepts in practice. The code is also accessible as a GitHub repository.
Continue reading →

This article shows how to install IntelliJ IDEA on Raspberry Pi. The instructions are also applicable for other IDEA-based IDEs like PyCharm, RubyMine, PhpStorm, WebStorm, CLion, etc.

At first, the idea of installing a full-fledged, contemporary IDE on Raspberry Pi may seem unrealizable. Raspberry Pi boards are incredibly small, so it’s hard to believe that those devices are apt for such a task. Nevertheless, in reality, Rasperry Pi can do much, much more than blinking a LED.

After trying out Scala on Raspberry Pi for some time, I configured my Rasperry Pi to run IDEA & Scala plugin for the recent ScalaDays conference. While it was initially intended to be just a “proof of concept”, it turned out that we were able to open the Scala plugin project itself (which is pretty large, and includes all IDEA CE sources) and to comfortably use this setup for most feature demonstrations. Obviously, it’s unreasonable to expect desktop-like performance from such a device, however I happen to successfully use a similar environment on EEE PC which was hardly faster.

The instructions rely on the following keystones that make the undertaking possible (and even practical):

• Raspberry Pi 2 Model B, which offers a 900MHz quad-core CPU and 1GB of RAM (this one is for the “practical” part, yet you may try to use Rasperry Pi 1 as well).

• Oracle JDK 8 for ARM (with HardFP, JIT and server VM), which provides >10X performance boost (comparing to Zero VM from OpenJDK).

• Small, but essential modifications that enable IntelliJ IDEA to run on ARM systems, like Raspberry Pi (you may use the same techniques for other ARM-based microcomputers).

Update: we’ve fixed the incompatibilities, so IDEA 15 (or later) should be able to run on ARM architecture (including RaspberryPi) out-of-the-box.

Contents:

1. Installing Java
2. Installing IDEA
3. Tweaking Raspberry Pi
4. Tweaking IDEA

Some of the commands will require root privileges, so either login as root user or use sudo to start an interactive shell via sudo -i.
Continue reading →

This article shows how to install and use Scala programming language on Raspberry Pi.

Traditionally, the programming language of choice for Raspberry Pi was Python, while JVM-based languages were set aside. That was reasonable, because JVM platform is rather resource-intensive, especially in interpreted mode, and the first version of Raspberry Pi was hardly apt for such a task.

However, things have changed: on the one hand, Raspberry Pi 2 now offers a 900MHz quad-core CPU and 1GB of RAM, on the other hand, Oracle released JDK 8 for ARM (with HardFP, JIT and server VM), which provides >10X performance boost (comparing to Zero VM from OpenJDK), so Scala runs nicely even on Raspberry Pi 1 (and, RPi 2 can run IntelliJ IDEA, if you wish).

Contents:

1. Installing Java
2. Installing Scala
3. Using Scala
4. Installing SBT
5. Using SBT

Some of the commands will require root privileges, so either login as root user or use sudo to start an interactive shell via sudo -i.
Continue reading →

About a year ago I happen to devise a solution (spoiler!) to a puzzle latter known as “Twitter’s waterflow problem”. Despite the number of alternative solutions, my original approach still stand out in its own way, and can be used to demonstrate a few peculiar things about recursion and list folding.

The puzzle probably existed before Twitter itself, yet it received great popularity after Michael Kozakov’s post about his interview at Twitter. As Reddit commenter noticed, “luxury of time and hindsight are wonderful things indeed”, so here goes the problem specification.

Specification

We are given a list of numbers, representing walls of different height. The goal is to determine how much rain water can be accumulated between the walls.

Here’s a visual representation of [2,5,1,2,3,4,7,7,6]:

In this case, the amount of accumulated water is 10 (note that there are no implicit side walls).

Requirements

Because of the puzzle popularity, many solutions, in different programming languages, were posted:

• Comments to Michael’s Gist (spoiler!)
• Comments on Reddit (spoiler!)

Approach, conciseness, performance and even correctness of those solutions vary greatly. What kind of solution do we want? It must be:

• efficient (O(n)time complexity),
• concise (1-5 lines of code),
• compatible with linear-access sequences (like list),
• preferably “functional”.

Now you may take your time and try to solve this problem by yourself before reading any further. In this way, you will not only enjoy a rather cute puzzle, but be able to comprehend with greater clarity what I’m going to show next.
Continue reading →

This article presents a list of simplifications and optimizations of typical Scala Collections API usages.

Some of the tips rest upon subtle implementation details, though most of the recipes are just common sense transformations that, in practice, are often overlooked.

The list is inspired by my efforts to devise practical Scala Collections inspections for the IntelliJ Scala plugin. We’re now in process of implementing those inspections, so if you use the plugin in IDEA, you’ll automatically benefit from static code analysis.

Nevertheless, the recipes are valuable by themselves and can help you to deepen your understanding of Scala Collections and to make your code faster and cleaner.

Update:
If you feel adventurous, you can learn how to contribute to IntelliJ Scala plugin and try your hand at “up for grabs” collection inspections that are to your liking.

The article is also (independently) translated into Russian and Chinese (one more translation).

Contents:

1. Legend
2. Composition
3. Side effects
4. Sequences
   4.1. Creation
   4.2. Length
   4.3. Equality
   4.4. Indexing
   4.5. Existence
   4.6. Filtering
   4.7. Sorting
   4.8. Reduction
   4.9. Matching
   4.10. Rewriting
5. Sets
6. Options
   6.1. Value
   6.2. Null
   6.3. Processing
   6.4. Rewriting
7. Maps
8. Supplement

All the code examples are available as a GitHub repository.
Continue reading →

This article shows how Scala adopts and transforms the classical software design patterns.

The content of the article is also (independently) translated into Russian and Chinese.

Design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished code, but rather a template for how to solve a problem that can be used in many different situations.

Patterns are formalized best practices of effective design, which helps to prevent subtle issues, improve code readability and speed up the development process.

The classical design patterns (mostly, the GoF patterns) are object-oriented. They show relationships and interactions between classes and objects. These patterns are less applicable in pure functional programming (see Haskell’s Typeclassopedia and Scalaz for “functional” design patterns, kind of), however, since Scala is an object-functional hybrid language, these patterns are still very relevant, even in “functional” Scala code.

Sometimes, design patterns may be a sign of some missing feature in a programming language. In such cases, the patterns might be simplified or eliminated when a programming language provides the required features. In Scala, it’s possible to implement most classical design patterns directly, relying on the expressive language syntax.

While Scala may employ additional, language-specific design patterns, this article focuses on the well-known, classical patterns, because these patterns also serve as the means of communication between developers.

Sure we can use the Force all the power of Scala to completely transcend all these patterns, but in this article I intentionally tried to avoid more advanced techniques in favor of more simple and pictorial ones, in order to provide a clean mapping between languages.

Creational patterns:

• Factory method
• Lazy initialization
• Singleton

Structural patterns:

• Adapter
• Decorator

Behavioral patterns:

• Value object
• Null Object
• Strategy
• Command
• Chain of responsibility
• Dependency injection

So, here goes the patterns (all the code is available as a GitHub repository).
Continue reading →

The famous Ninety-Nine Prolog problems (by Werner Hett) transcended their original purpose and became a popular set of exercises for languages other than Prolog.

Solving these puzzles (and comparing your solutions with solutions of others) is a good way to “get a feel” for programing language and to explore idiomatic approaches to particular kind of problems.

Today we can easily find solutions to the problems in almost any wide-spread programming language. However most of the attempts use a single programing language and provide only one solution to each problem.

By providing multiple types of solutions we can enrich our programming “toolbox” and learn pros and cons of various methods. By using several programming languages simultaneously we can easily correlate different programming paradigms and explore limits of language expressive power.

Here goes my take on Ninety-Nine Problems in:

• Scala,
• Java,
• Clojure,
• Haskell.

All the code is available as a GitHub repository.
Continue reading →