You should choose exactly one pixel on the screen, and exactly one channel between red, green and blue, and make its value either always 0 or always maximum (usually 255). The values of other channels should be the same as if your program didn't run.

You can choose the pixel and channel in whatever ways, such as hardcoding it or generate it randomly on each run. But it must always be visible on fairly modern hardwares.

If the color that originally should be displayed on that pixel has changed, your program should update in less than 0.5 seconds when the system is fast enough.

You cannot make assumptions about what is currently displayed on the screen (such as a taskbar using the default theme).

Your program doesn't need to work when a screensaver, login screen, effect from a window manager, etc, are active.

Shortest code wins.

• Can we assume a specific OS? – Loovjo Dec 11 '16 at 15:01
• @Loovjo Yes, you can. – jimmy23013 Dec 11 '16 at 16:00
• Ow... the requirement to preserve the other channels probably doubles my already-ridiculous byte count. – Bob Dec 12 '16 at 3:41

# Bash on Linux - 25 bytes of Latin-1

+3 from @wyldstallyns / -2 from removing quotes / -1 because I forgot how this works / -9 from @Dennis

printf ÿ>/dev/fb0;exec $0  Assumes that /dev/fb0 exists (it does on my Arch Linux system, and I think it should on any other Linux system). Requires root access as well. This does not work for me when X is running. On my system, this just constantly sets the blue channel of the top-left pixel to full (ÿ is 255). • You need echo -n - otherwise this could golf to: yes ff>/dev/fb0 – wyldstallyns Dec 11 '16 at 18:01 • @wyldstallyns Yeah, I've fixed it accordingly. AFAIK, printing the newline would influence more than one pixel (not allowed by challenge description) – artificialnull Dec 11 '16 at 18:08 • How is ÿ 255? I don't think this works. 255 is not a valid unicode character, it's not ascii either, so it must rely on one of those ancient codepages that shouldn't ever be used, as they differ from machine to machine. – orion Dec 11 '16 at 19:51 • printf ÿ>/dev/fb0;exec$0 saves a few bytes. – Dennis Dec 11 '16 at 19:59
• @orion The yes approach doesn't work. /dev/fb0 has to be reopened after writing one pixel channel. – Dennis Dec 11 '16 at 20:04

# Visual C++, 10210099 98 bytes

#include<Windows.h>
int main(){for(HDC d=GetDC(0);;Sleep(99))SetPixel(d,9,9,GetPixel(d,9,9)|255);}


Runs on Windows, directly using the Win32 API with Visual C++ compiler targeting the console subsystem. Uses the "screen" device context to set the red channel of the pixel at (9,9) to 0xFF.

The sleep is necessary to allow other programs to draw in between the get/set - and 9ms was too short, leading to the pixel getting stuck1 on its initial colour.

1 Unfortunately, not quite the same type of stuck pixel this question is looking for...

# HolyC, 13 bytes

GrPlot(,9,9);


Puts a black dot on the persistent layer directly.

What it looks like.

# C#, 247244371366354 352 bytes

Runs on Windows. Gets a device context for the entire screen, and repeatedly maximises the red channel at (9,9).

namespace System.Runtime.InteropServices{using I=IntPtr;class P{[DllImport("User32")]static extern I GetDC(I h);[DllImport("Gdi32")]static extern int GetPixel(I h,int x,int y);[DllImport("Gdi32")]static extern int SetPixel(I h,int x,int y,int c);static void Main(){for(I d=GetDC((I)0);;Threading.Thread.Sleep(99))SetPixel(d,9,9,GetPixel(d,9,9)|255);}}}


I originally didn't want to import GetPixel/SetPixel, but there's no particularly easy way to read a single pixel off a Graphic. So right now this is effectively the same as my VC++ attempt. Maybe saving to bitmap will be shorter...

-5 bytes thanks to @TuukkaX

• You can remove the whitespaces from the parameter list of SetPixel. – Yytsi Dec 12 '16 at 5:41
• @TuukkaX Thanks! Missed those. – Bob Dec 12 '16 at 6:14
• You can make it sleep for 9ms rather than 99ms – Rob Dec 12 '16 at 6:18
• @Rob I tried that, as mentioned in the C++ answer. Unfortunately, 9ms didn't seem to be enough when I tested (Win7). Other programs did not have enough time to paint, so the pixel effectively got stuck on its initial colour. – Bob Dec 12 '16 at 6:25
• Could also shorten it by running through about 0x1FFFFFFF iterations in a busy loop instead of the sleep, but this would have to be tuned for every machine to stay within the 0.5s limit. – Bob Dec 12 '16 at 6:43

# SmileBASIC, 20 bytes

SPSET.,299,99,1,1,33


Sets sprite 0 to a 1x1 area at 299,99 on the sprite sheet (which is a red pixel).
33 is the display attribute, which is 1 (display on) + 32 (additive blending).

# Java 7, 266 bytes

import java.awt.*;public class K extends java.applet.Applet{public static void main(String[]a){new K();}Label l=new Label(".");public K(){add(l);}public void paint(Graphics g){s(Color.red);s(Color.green);s(Color.blue);repaint();}void s(Color c){l.setForeground(c);}}


I ran this on windows 7. Opens a Java Applet which has a white background by default. Adds a label with a period and then changes the color of the label ad nauseum.

• Not actually sure if this is valid since it only changes the pixel in the applet window. Won't change the pixel color if the applet loses focus... I'll delete this answer if it doesn't meet the challenge's criteria. – Poke Dec 12 '16 at 20:57

# Tcl/Tk, 61

wm at . -tr #F0F0F0
wm o . 1
grid [canvas .c]
.c cr o 9 9 9 9


On the image there is a black pixel near the upper left corner of the Vivaldi icon:

If on an interactive shell, there are abbreviations of commands available:

# Tcl/Tk, 57

wm at . -tr #F0F0F0
wm o . 1
gri [can .c]
.c cr o 9 9 9 9


There is a black pixel over the V white area of the Vivaldi icon: