From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: GDI+ take 3 Date: Mon, 20 Apr 2020 16:54:00 +0300 Message-ID: <834ktei7pj.fsf@gnu.org> References: <83d088fwgt.fsf@gnu.org> <835ze0fqk2.fsf@gnu.org> <83sgh3eogs.fsf@gnu.org> <838sitazal.fsf@gnu.org> <86imhxufx9.fsf@csic.es> <83y2qsap7r.fsf@gnu.org> <20200418201943.GA57763@breton.holly.idiocy.org> <83eesjibo6.fsf@gnu.org> <86368zxlsn.fsf@csic.es> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="85178"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Juan =?utf-8?Q?Jos=C3=A9_Garc=C3=ADa-Ripoll?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 20 15:54:57 2020 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 1jQWsy-000M2u-AA for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Apr 2020 15:54:56 +0200 Original-Received: from localhost ([::1]:36198 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQWsx-00079v-CH for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Apr 2020 09:54:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37120 helo=eggs1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQWsA-0006Mj-Bf for emacs-devel@gnu.org; Mon, 20 Apr 2020 09:54:06 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:47325) by eggs1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQWsA-0004xd-4C; Mon, 20 Apr 2020 09:54:06 -0400 Original-Received: from [176.228.60.248] (port=4315 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jQWs9-00087J-Gh; Mon, 20 Apr 2020 09:54:05 -0400 In-Reply-To: <86368zxlsn.fsf@csic.es> (juanjose.garciaripoll@gmail.com) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:247385 Archived-At: > From: Juan José García-Ripoll > > Date: Sun, 19 Apr 2020 22:28:24 +0200 > > Two minor changes attached. First, the introduction of the Qnative_image > type makes one call to image_can_use_native_api irrelevant. That makes some assumptions I felt uneasy about. First, it assumes that the native_image entry will never have an init method; this could become wrong at some future point, at which time someone will have to remember to adapt initialize_image_type to handle that (since native_image doesn't really have a library to load). Second, what happens if the TYPE argument specifies an image type the native_image cannot handle (e.g., SVG), and the corresponding optional image library is not linked in or is unavailable at run time? With your patch, we would return true, right? So, all things considered, I think it is more future-proof to leave that call in place, at least until we make up our minds regarding the default configuration on MS-Windows. > Regarding this, I think it is a bad idea to introduce Qnative_image, > because that is not an image format and users cannot recognize the > actual image type from the image descriptor. I'm not sure I understand the issue. When you say "users", what do you mean in this context? If you mean users like me and you, then how and where would we see Qnative_image? The technical reason I introduced Qnative_image is that look up_image_type wants to return a struct, and its callers depend on that. Also, I thought about the use case where none of the optional image libraries are compiled in, in which case this will be the only element of that array. I shortly entertained the idea to put the requested image symbol (like Qpng etc.) there, but I didn't like the idea of changing a const struct. What would you propose to do instead? > The second fix makes w32image.c behave like nsimage.c, in that a delay=0 > is regarded as non-existant, thus returning nil. This makes animations > default to the minimum animation delay, which currently is 0.01, and > more useful than a delay of 0. You are right. However, I believe I already fixed that, albeit a bit differently, as part of commit 423089d (after bumping into the same problem during testing my recent changes). We can use your change instead, if you think it is better for some reason. Thanks.