Flat Decorator and ControlLook

Help
101

Today i was trying to recompile the Decorator; builds ok, but after selected in appearance settings nothing happen, and go back to the latest decorator (dont falls in debuggerland, but dont works).

Now i compile the BeDecorator (the latest sources from github) but after selected from appearance, the debuggerland appears with a segment violation… so, im not sure what its happen. Here is the report attached from beDecorator, the problem seems to be the _getButtonSizeAndOffset method: any help of an expert is apreciated.

Edit: this is in hrev55228

Debug information for team /boot/system/servers/app_server (604):
CPU(s): 4x Intel Core™ i5-3317U
Memory: 5.79 GiB total, 658.54 MiB used
Haiku revision: hrev55228 Jul 12 2021 06:24:43 (x86_64)

Active Threads:
	thread 604: app_server (main)
	thread 614: DMT is here for you, eventually 
	thread 629: Font Manager 
	thread 630: screen manager 
	thread 679: d:0:baron 
	thread 680: a:610:x-vnd.Haiku-SystemLogger 
	thread 681: a:645:x-vnd.haiku.userlandfs-se 
	thread 682: a:667:x-vnd.dw-AutoFiler 
	thread 683: a:608:x-vnd.Haiku-powermanageme 
	thread 684: a:605:x-vnd.Haiku-mount_server 
	thread 686: a:678:x-vnd.Be-input_server 
	thread 695: event loop 
	thread 696: cursor loop 
	thread 704: a:692:x-vnd.Be-TRAK 
	thread 710: w:692:Desktop 
	thread 717: a:699:x-vnd.Be.media-server 
	thread 728: a:702:x-vnd.Be-TSKB 
	thread 730: w:702:Deskbar 
	thread 733: a:715:x-vnd.Haiku-notification_ 
	thread 735: a:724:x-vnd.Be.addon-host 
	thread 737: w:715:Notification 
	thread 741: a:726:x-vnd.LnLauncher 
	thread 742: w:726:IconPanel 
	thread 750: w:726:IconPanel 
	thread 755: a:747:x-vnd.Haiku-keystore_serv 
	thread 774: w:702:Twitcher 
	thread 775: w:702:offscreen 
	thread 780: w:692:Tracker status 
	thread 786: w:692:objects.x86_64-cc8-releas 
	thread 788: w:692:decorators 
	thread 878: a:876:x-vnd.Haiku-Terminal 
	thread 880: w:876:Terminal: FlatDecorator:  
	thread 1118: w:1115:Appearance 
	thread 1124: team 604 debug task 
	thread 1117: a:1115:x-vnd.Haiku-Appearance 
		state: Exception (Segment violation)

		Frame		IP			Function Name
		-----------------------------------------------
		0x7f561730e8e0	0x127641fb747	BeDecorator::_GetButtonSizeAndOffset(BRect const&, float*, float*, float*) const + 0x7 
			Disassembly:
				BeDecorator::_GetButtonSizeAndOffset(BRect const&, float*, float*, float*) const:
				0x00000127641fb740:   488b8720020000  mov 0x220(%rdi), %rax
				0x00000127641fb747:         83784c19  cmp $0x19, 0x4c(%rax) <--

			Frame memory:
				[0x7f561730e8d8]  b.Y-s...   62 e9 59 2d 73 01 00 00
		0x7f561730e940	0x1732d59e95c	Decorator::AddTab(DesktopSettings&, char const*, window_look, unsigned int, int, BRegion*) + 0xac 
		0x7f561730e9d0	0x1732d59b59a	DecorAddOn::AllocateDecorator(Desktop*, DrawingEngine*, BRect, char const*, window_look, unsigned int) + 0xaa 
		0x7f561730ea10	0x1732d59b648	DecorManager::AllocateDecorator(Window*) + 0x68 
		0x7f561730eaa0	0x1732d596814	Window::ReloadDecor() + 0x64 
		0x7f561730eb50	0x1732d55b37e	Desktop::ReloadDecor(DecorAddOn*) + 0xae 
		0x7f561730ebc0	0x1732d59bef8	DecorManager::SetDecorator(BString, Desktop*) + 0x98 
		0x7f561730f6e0	0x1732d57190b	ServerApp::_DispatchMessage(int, BPrivate::LinkReceiver&) + 0x350b 
		0x7f561730f7b0	0x1732d574cf9	ServerApp::_MessageLooper() + 0x139 
		0x7f561730f7c0	0x1732d567437	MessageLooper::_message_thread(void*) + 0x7 
		0x7f561730f7e0	0x4ec04726a7	thread_entry + 0x17 
		00000000	0x7f5de9109260	commpage_thread_exit + 0 

		Registers:
			  rip:	0x00000127641fb747
			  rsp:	0x00007f561730e8d8
			  rbp:	0x00007f561730e930
			  rax:	0x0000000000000000
			  rbx:	0x000010fc6bc33820
			  rcx:	0x0000000000000000
			  rdx:	0x00000000ffffffff
			  rsi:	0x00007f561730e978
			  rdi:	0x000010fc6bec9a90
			   r8:	0x000010fc6bb54d3b
			   r9:	0x0000000000000000
			  r10:	0x0000000000000001
			  r11:	0x0000000000000001
			  r12:	0x000010fc6bec9a90
			  r13:	0x00000000ffffffff
			  r14:	0x000010fc6bec9a98
			  r15:	0x000010fc6bec9d10
			   cs:	0x002b
			   ds:	0x0000
			   es:	0x0000
			   fs:	0x0000
			   gs:	0x0000
			   ss:	0x0023
			  st0:	nan
			  st1:	nan
			  st2:	nan
			  st3:	nan
			  st4:	3.25e+04
			  st5:	7.65e+06
			  st6:	1e+05
			  st7:	9.98e+07
			  mm0:	{0, 0, 0, 0}
			  mm1:	{0x400, 0, 0, 0}
			  mm2:	{0x4000, 0xffb1, 0, 0}
			  mm3:	{0x17, 0, 0, 0}
			  mm4:	{0, 0, 0, 0xfdfe}
			  mm5:	{0, 0, 0xecc, 0xe95e}
			  mm6:	{0, 0, 0x8000, 0xc357}
			  mm7:	{0x1c1a, 0x5e05, 0xf928, 0xbe61}
			 ymm0:	{0x9811, 0x4235, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
			 ymm1:	{0x2f1c, 0x3f6d, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
			 ymm2:	{0, 0x4244, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
			 ymm3:	{0xb5c3, 0x4301, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
			 ymm4:	{0xb9bb, 0x431a, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
			 ymm5:	{0xb99a, 0x4352, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
			 ymm6:	{0, 0x434e, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
			 ymm7:	{0, 0x42e6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
			 ymm8:	{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
			 ymm9:	{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
			ymm10:	{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
			ymm11:	{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
			ymm12:	{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
			ymm13:	{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
			ymm14:	{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
			ymm15:	{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}

Loaded Images:
	ID		Text Base	Text End	Data Base	Data End	Type	Name
	--------------------------------------------------------------------------------
	2306	0x2198d08000	0x2198d09000	0x2198f08000	0x2198f09000	lib    	/boot/system/lib/libicudata.so.66.1
	2475	0x408a938000	0x408a953000	0x408ab53000	0x408ab54000	add-on 	/boot/system/add-ons/accelerants/intel_extreme.accelerant
	2381	0x4092746000	0x4092827000	0x4092a27000	0x4092a29000	lib    	/boot/system/lib/libiconv.so.2.6.1
	2313	0x4238a9b000	0x4238adb000	0x4238cda000	0x4238ce3000	lib    	/boot/system/lib/libnetwork.so
	2307	0x4421206000	0x44214ee000	0x44216ed000	0x4421705000	lib    	/boot/system/lib/libicui18n.so.66.1
	2304	0x4ec0435000	0x4ec0543000	0x4ec0743000	0x4ec0795000	lib    	/boot/system/lib/libroot.so
	2302	0x5445bae000	0x5445d10000	0x5445f0f000	0x5445f23000	lib    	/boot/system/lib/libstdc++.so.6.0.25
	2311	0x83d8247000	0x83d8263000	0x83d8462000	0x83d8463000	lib    	/boot/system/lib/libz.so.1.2.11
	2310	0x95c7a53000	0x95c7c1c000	0x95c7e1c000	0x95c7e32000	lib    	/boot/system/lib/libicuuc.so.66.1
	2312	0x9b60092000	0x9b6015e000	0x9b6035d000	0x9b6035e000	lib    	/boot/system/lib/libzstd.so.1.4.5
	2378	0xa9e95b1000	0xa9e95ba000	0xa9e97ba000	0xa9e97bb000	lib    	/boot/system/lib/libintl.so.8.1.5
	2309	0xaa1313c000	0xaa1316c000	0xaa1336b000	0xaa1339f000	lib    	/boot/system/lib/libicutu.so.66.1
	2295	0xaaf10f2000	0xaaf11a6000	0xaaf13a6000	0xaaf13ad000	lib    	/boot/system/lib/libfreetype.so.6.17.4
	2316	0xc112d60000	0xc112d70000	0xc112f6f000	0xc112f71000	lib    	/boot/system/lib/libbz2.so.1.0.8
	2282	0xc1250af000	0xc125116000	0xc125315000	0xc12531a000	lib    	/boot/system/lib/libbnetapi.so
	2315	0xcc1bce2000	0xcc1bd67000	0xcc1bf66000	0xcc1bf73000	lib    	/boot/system/lib/libssl.so.1.1
	2281	0xcda65b3000	0xcda68cd000	0xcda6acc000	0xcda6afa000	lib    	/boot/system/lib/libbe.so
	2280	0xcf7f810000	0xcf7f825000	0xcf7fa24000	0xcf7fa26000	lib    	/boot/system/lib/libtranslation.so
	2314	0xf121321000	0xf121530000	0xf121730000	0xf12175f000	lib    	/boot/system/lib/libcrypto.so.1.1
	2299	0xfcdb377000	0xfcdb472000	0xfcdb671000	0xfcdb674000	lib    	/boot/system/lib/libtextencoding.so
	8105	0x127641f8000	0x12764200000	0x12764400000	0x12764401000	add-on 	/boot/home/config/non-packaged/add-ons/decorators/BeosDecorator
102

The ControlLook appears to work ok!

screenshot2

3 Likes
103

I know you are asking about the decorator crash but just wanted to say your control look is nice. I also really like that wallpaper, do you have a link?

The window decorator also looks nice but would really benefit from the system having window shadows.

7 Likes
104

Is it possible for you to share this hpkg somewhere so we can investigate?

105

The package is in Haikuports repo.
You can find code here.

3 Likes
106

Why is it not possible to do window shadowing other than the lack of 3D hardware acceleration capabilities and what not to do the computation for such visualization?

107

It should be possible to do it with the CPU, it just complicates the drawing code in app_server and it would be easier to do with a compositing architecture, which is not how the app_server works right now. I don’t think anyone has really sat down and tried to do the shadows, though there was some work to switch app_server to use compositing. Though I’m sure that is really out of date now. Long term that is probably the direction app_server needs to go it just uses a bit more memory. If we could be really clever maybe we could have both methods and could switch to compositing on faster machines with more RAM.

4 Likes
108

Interestingly, SerenityOS implemented windows shadows earlier this year
WindowServer: Implement simple window shadows by tomuta · Pull Request #5272 · SerenityOS/serenity · GitHub

2 Likes
109

I don’t agree that no compositing is out of date. Compositing is not needed if there are no special graphics effects for windows such as shadows, transparency and animations with distortions. I see no meaning in such effects and usually disable it on all systems I use.

Compositing consumes A LOT of memory. Each window must allocate two 32 bit buffers for buffer swapping. Haiku often use a lot of windows and memory usage can grow dramatically. Other OS tends to use less windows.

When implementing 3D hardware acceleration I consider to use one surface for whole app_server 2D graphics including all windows and views and separate double buffered surface for each accelerated context. BDirectWindow mechanism can be reused to manage clipping of accelerated surfaces and app_server 2D graphics.

8 Likes
110

It use per-window compositing.

111

You misinterpreted my sentence, I was saying the compositing work that was done by looncraz in a branch is likely really out of date.

I agree compositing has a potentially high cost. Probably in theory shadows could be done without having to do compositing? But someone would have to see. The code might be quite complex.

112

Is it different from what we have in app_server? What are your thoughts on this proposal

@looncraz I couldn’t find your fork with compositing app_server, is it still online somewhere?
Would be interesting to know what do you think about this topic too.

113

At least Windows XP managed to get shadows without compositing. It is possible to draw shadows in the same way as cursor and drag&drop image.

2 Likes
114

Hi @tqh, the code is here: GitHub - unarix/haiku_darkstyle: Haiku-os ControlLook & Decorator for darkFlat, moonFlat and lightFlat UI mode.

The ControlLook appears to work ok, but the problem is the decorator (haiku_darkstyle/FlatDecorator at master · unarix/haiku_darkstyle · GitHub), i dont know why after selected nothing happens.

So, to ensure that the problem is not my code, i compile the BeDecorator (haiku/BeDecorator.cpp at 8f16317a5b6db5c672f331814273e5857555020f · haiku/haiku · GitHub) using the sames includes that are in my repo. After selected all systema fall in debuggerland whith a sement violation.

1 Like
115

I made an illustration of my 3D hardware acceleration architecture proposal:

Hardware graphics acceleration architecture

It introduce new native Haiku API for rendered buffer producers and consumers. It works in a way similar to Media Kit. Application that will render 3D graphics with OpenGL or Vulkan will expose BufferProducer interface that can be connected to BufferConsumer interface providers such as screen of compositor that will mix multiple inputs to one output. Connection is represented by SwapChain object that owns rendering buffers and control buffer swapping process. Connected BufferProducer and BufferConsumer may be in separate processes.

OpenGL or Vulkan applications are not required to have a window, it may be connected to another process BufferConsumer or to some offscreen processing BufferConsumer such as video recorder or network transmitter.

One screen-global surface is used for app_server 2D graphics so changes to app_server architecture and increase of resource usage would be minimal. app_server will provide clipping information to compositor by reusing BDirectWindow mechanism.

Applications do not directly talk to a compositor, it can request BufferConsumer interface for BWindow, BView or BScreen instead.

18 Likes
116

Yes. app_server use global rendering buffer and non-intersecting region clipped drawing areas. The same approach is used in Mac OS Classic, Windows 1.0 - XP, X11 without compositing.

This approach attempts to introduce mandatory per-window compositing and client side 2D rendering. It will require major rework of app_server and libbe.so. app_server will need to be rewritten almost from scratch. It may cause difficulties with printing and remote desktop because of client side 2D rendering instead of sending vector drawing commands to app_server. Because of per-window compositing it will cause significant increase of memory usage.

6 Likes
117

This is interesting, but probably should be its own topic?

3 Likes
118

I did a core dump from debugger with the one in HaikuDepot. I’ll see if I can use that core dump when the UI is running properly. Travelling around though, so little time for computers. Thanks for the detailed info.

119

Thanks for the help @tqh! Maybe @jscipione or @nephele can help too, i think that not too much time ago they made some changes in the api (if I remember correctly)

120

Thanks @leavengood! I downloaded the wallpaper from internet, so i think that i can share it: https://tinyurl.com/en78xjsb