summaryrefslogtreecommitdiff
path: root/docs/new-api
blob: f24a6daecc5c5b48cca4afae797320cf41e48f98 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
It may be interesting to look at a radically different API, in which

- there is a pixman_context_t
- you can set things like "src", "dst", "mask", "src_x", src_format
  and so on, and then once all the state is set up, you call 
  
	pixman_composite (pixman_context_t *context);

- An additional API could then take a list of key/value commands that would
  set these variables. Ie., 

	pixman_submit (
		context, 
		PIXMAN_BEGIN_SRC,
		    PIXMAN_IMAGE_TYPE, solid,
	            PIXMAN_COLOR, color,
		PIXMAN_END_SRC,
		PIXMAN_DEST_DATA, my_data,
		PIXMAN_MASK_DATA, data,
		PIXMAN_CLIP_REGION, &clip,
		PIXMAN_BEGIN_COMPOSITE,
		PIXMAN_POLYGON_DATA, "...",
		PIXMAN_CALLBACK, function, data,
		...);

  and so on. This would be precisely equivalent to setting a bunch of
  state and then calling pixman_composite().

  There could be helper functions

	list = pixman_begin_command_list (context)
	pixman_commands (
		list, 
		PIXMAN_SOURCE_DATA, my_data,
		...);
	pixman_end_command_list (list);


Issues:

- PIXMAN_IMAGE_ADDRESS	blah	// For software

- PIXMAN_IMAGE_BO	bo	// For hardware

Should pixman decide the location of images, or should the
application? In general, who should make this decision.

pixman can't take all such decisions because framebuffer objects will
not be created by pixman. Hence pixman will need to deal with objects
in video memory and the corresponding software fallbacks.

Also, the API above is restricting to one src/mask/dest image, but it
might be useful to compile a complete "expression" tree. It would be
difficult to extract such a tree from a command stream. On the other
hand, such a tree could conveniently be compiled into a command stream
that would compositing onto destination rectangles. 

Which suggests that setting a render target should be something other
than setting a source. Ie., it would be useful to set a destination
plus a destination clip, and then different sources and masks. A
stream would then compile everything related to one destination
into one program.

States could be cached with edges in the state graph labeled with
SET_STATE commands. Then fast paths or compiled code could be cached
on these states.

However, to be able to cache full shader programs, commands also need
to trigger transitions.