From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: MPS: scroll-bars Date: Sat, 04 May 2024 11:47:43 +0300 Message-ID: <86h6fegdzk.fsf@gnu.org> References: <875xvvp3fo.fsf@gmail.com> <87r0eicht1.fsf_-_@gmail.com> <87plu29lcc.fsf@yahoo.com> <87fruyccs8.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26007"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eller.helmut@gmail.com, luangruo@yahoo.com, emacs-devel@gnu.org To: Gerd =?utf-8?Q?M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 04 10:48:36 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1s3B4O-0006b4-HL for ged-emacs-devel@m.gmane-mx.org; Sat, 04 May 2024 10:48:36 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s3B3f-000498-06; Sat, 04 May 2024 04:47:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s3B3b-00047o-FV for emacs-devel@gnu.org; Sat, 04 May 2024 04:47:47 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s3B3b-0002AF-6e; Sat, 04 May 2024 04:47:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=H12sGuvuK98S3A/1oJd3izqOEWcFonH4qRW5f1TxWT8=; b=BIl4xZkABWZNmX8RVwU6 tT0HHmjsUz2dy6vKIUpaiwyCP8sQeuj7j6ruiNzR4RaKR/1ohDID1mSRQXqV4ExB5tFOJRvdK+OzY kSBWRnu9oCNg/rvKX9T+Ha/YmkFQoymZY6y42E7egeY0GeSWmWUMIzUfRBr3aRePzr3jrj/9KeghL kI1nJ4LSfNR+tklE/tvvtUFCy7uERLE5uaJvRKB4KVhlS1t3o69HQTEYGbBB0hbVYiaJNqfGHWy3E IEEApbyEPO/Gx3ZsdYyiS5f/iWFtCrPDGkpBpX8L6wbqedNxcmSykjyB9hNHLpW4E6sqvzIzoi5jL ftK1WfreT1ozew==; In-Reply-To: (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Sat, 04 May 2024 09:09:00 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:318726 Archived-At: > From: Gerd Möllmann > Cc: Po Lu , Eli Zaretskii , Emacs Devel > > Date: Sat, 04 May 2024 09:09:00 +0200 > > > #define XSCROLL_BAR(vec) ((struct scroll_bar *) XVECTOR (vec)) > > > > Nice, nice :-) > > So, maybe this is also interesting on other platforms, who knows... > > struct window has members for scroll bars, e.g. > > Lisp_Object vertical_scroll_bar; > > These Lisp_Objects are either fixnums or Lisp_Misc_Ptrs (see function > xmint_ptr in lisp.h). That's not what I see on w32. Here's what I see: static void w32_set_vertical_scroll_bar (struct window *w, int portion, int whole, int position) { Lisp_Object barobj; struct scroll_bar *bar; [...] /* Does the scroll bar exist yet? */ if (NILP (w->vertical_scroll_bar)) { [...] bar = w32_scroll_bar_create (w, left, top, width, height, false); } [...] XSETVECTOR (barobj, bar); wset_vertical_scroll_bar (w, barobj); And w32_scroll_bar_create does: static struct scroll_bar * w32_scroll_bar_create (struct window *w, int left, int top, int width, int height, bool horizontal) { struct frame *f = XFRAME (WINDOW_FRAME (w)); [...] struct scroll_bar *bar = ALLOCATE_PSEUDOVECTOR (struct scroll_bar, w32_widget_high, PVEC_OTHER); Lisp_Object barobj; block_input (); XSETWINDOW (bar->window, w); bar->top = top; bar->left = left; bar->width = width; bar->height = height; bar->start = 0; bar->end = 0; bar->dragging = 0; bar->horizontal = horizontal; /* Requires geometry to be set before call to create the real window */ if (horizontal) hwnd = my_create_hscrollbar (f, bar); else hwnd = my_create_vscrollbar (f, bar); [...] /* Add bar to its frame's list of scroll bars. */ bar->next = FRAME_SCROLL_BARS (f); bar->prev = Qnil; XSETVECTOR (barobj, bar); fset_scroll_bars (f, barobj); if (! NILP (bar->next)) XSETVECTOR (XSCROLL_BAR (bar->next)->prev, bar); My conclusions: . scroll-bar Lisp object is a pseudovector . w->vertical_scroll_bar is set to the window's scroll-bar object . scroll-bar objects of a frame are stored in a doubly-linked list via the ->prev and ->next C pointers of 'struct scroll_bar' . frame's f->scroll_bars points to the last scroll-bar object created for the frame's windows, and thus effectively to the linked list of the frame's scroll bars . similarly, a frame has f->condemned_scroll_bars, which is a doubly-linked list of condemned scroll bars, the ones that could be deleted as result of redisplay (e.g., because their window were deleted) Moreover (and this is w32-specific, I think), the Lisp thread sends a GUI message to the UI thread with the pointer to 'struct scroll_bar', via the call to my_create_hscrollbar: case WM_EMACS_CREATEVSCROLLBAR: return (LRESULT) w32_createvscrollbar ((struct frame *) wParam, (struct scroll_bar *) lParam); static HWND my_create_vscrollbar (struct frame * f, struct scroll_bar * bar) { return (HWND) SendMessage (FRAME_W32_WINDOW (f), WM_EMACS_CREATEVSCROLLBAR, (WPARAM) f, (LPARAM) bar); <<<<<<<<<<<<<<<<<<<<<<<< } the UI thread then uses the members of 'bar' like this: static HWND w32_createvscrollbar (struct frame *f, struct scroll_bar * bar) { HWND hwnd = CreateWindow ("SCROLLBAR", "", /* Clip siblings so we don't draw over child frames. Apparently this is not always sufficient so we also try to make bar windows bottommost. */ SBS_VERT | WS_CHILD | WS_VISIBLE | WS_CLIPSIBLINGS, /* Position and size of scroll bar. */ bar->left, bar->top, bar->width, bar->height, FRAME_W32_WINDOW (f), NULL, hinst, NULL); So, what does this mean in the MPS build? I guess we need to make sure scroll bars don't move, for the reference across threads to work? I see that allocate_pseudovector does: struct Lisp_Vector * igc_alloc_pseudovector (size_t nwords_mem, size_t nwords_lisp, size_t nwords_zero, enum pvec_type tag) { struct Lisp_Vector *v = alloc (header_size + nwords_mem * word_size, IGC_OBJ_VECTOR, tag); XSETPVECTYPESIZE (v, tag, nwords_lisp, nwords_mem - nwords_lisp); maybe_finalize (v, tag); return v; } But still for the life of me I don't really understand what that means for us in this case. What does it mean for the references to its C 'struct scroll_bar' when the scroll-bar object is moved? If any of these references are on some thread's stack, does it mean the object will not move? And what about those prev and next pointers in frame's scroll_bars lists -- do we need to do anything with them? Likewise with the window's vertical_scroll_bar pointers.