Re: [JAVA2D] Dynamics of acceleration of BufferedImages ("managed images")

Thu, 11 Sep 2008 11:09:28 -0700 

  Mike is exactly right.

  Dmitri

Nidel, Mike wrote:

I don't strictly disagree, but one of the reasons for abstraction like
this is to enable your own development team to change the implementation
without having to change the API. I may be wrong, but my sense is that
this has been a motivating factor for the Java2D team.

Once you allow developers to peek under the hood, then they start
optimizing their code using the low-level components and bypassing
the abstractions you've created. Then when you make changes to the
underlying objects and their interactions, it breaks everyone's
applications because they relied on those interactions.

To make a gross generalization, to me this is the difference between
thinking like a C/C++ developer versus a Java developer. Java builds
in so many abstractions, from garbage collection to Swing to stuff
like managed images. In my opinion, C++ development generally exposes
more of the underlying workings of the components. That's not to say
one or the other is objectively better, obviously every tool has its
use, but I'm giving a reason why a system developer might not want to
expose the inner implementation of their system.

That's just my take when trying to see it from the other side.

Mike


-----Original Message-----
From: Discussion list for Java 2D API [mailto:[EMAIL PROTECTED] On Behalf Of Ken Warner 
Sent: Thursday, September 11, 2008 12:54 PM
To: [EMAIL PROTECTED]
Subject: Re: [JAVA2D] Dynamics of acceleration of BufferedImages ("managed images") 

Dmitri Trembovetski wrote:
That's the idea. The developer shouldn't be worrying about this stuff, 
   it should work for most cases. For those cases where the user needs
tweaking or resource management there are APIs like setAcceleratedPriority 
   and the like.

------
That's exactly the kind of stuff what a real programmer should be worrying about. And what if someone (like me or the author of this thread) run into a case where it doesn't quite work the way we want it to? We're screwed because we can't get to the foundation classes to fix the problem.
Give us the primitives and let us figure out how to use them. You (the Java Dev Team) are trying to do too good a job.
The first accessible layer should be the primitives (well documented) and then you can layer higher level API's on top for accessabliity and ease of use for less accomplished programmers.
High level API's as you've implemented in Java2D are really useful and make the job a whole lot easier. But there are times when you really need the low level stuff at your finger tips so you *CAN* change stuff. 

==============================================================
=============
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
mailgw3.lmco.com with ESMTP id m8BH4ZcP017142; Thu, 11 Sep 2008 13:04:35 -0400 (EDT) 
Received: from swjscmail2.sun.com (swjscmail2.Sun.COM [192.18.99.108])
by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m8BGtCvR019976; 
        Thu, 11 Sep 2008 16:55:29 GMT
Received: from swjscmail1 (swjscmail1.Sun.COM [192.18.99.107])
by swjscmail2.sun.com (8.11.7p3+Sun/8.11.7) with ESMTP id m8BGsFj05970; 
        Thu, 11 Sep 2008 10:54:15 -0600 (MDT)
Received: by JAVA.SUN.COM (LISTSERV-TCP/IP release 15.0) with spool id 2358172 for [EMAIL PROTECTED]; Thu, 11 Sep 2008 10:54:32 -0600 Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by swjscmail1.java.sun.com (Postfix) with ESMTP id AEE023A82E for <[EMAIL PROTECTED]>; Thu, 11 Sep 2008 10:54:31 -0600 (MDT) Received: from relay23.sun.com (relay23.sun.com [192.12.251.54] (may be forged)) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m8BGojCC016809 for <[EMAIL PROTECTED]>; Thu, 11 Sep 2008 
          16:54:57 GMT
Received: from mms24es.mms.us.syntegra.com ([150.143.232.70] [150.143.232.70]) 
          by relay23i.sun.com with ESMTP id BT-MMP-3418417 for
          [EMAIL PROTECTED]; Thu, 11 Sep 2008 16:54:56 Z
Received: from relay21.sun.com (relay21.sun.com [192.12.251.24]) by
mms24es.mms.us.syntegra.com with ESMTP id BT-MMP-111927369 for 
          [EMAIL PROTECTED]; Thu, 11 Sep 2008 16:54:56 Z
Received: from vms173003pub.verizon.net ([206.46.173.3] [206.46.173.3]) by 
          relay21i.sun.com with ESMTP id BT-MMP-5067960 for
          [EMAIL PROTECTED]; Thu, 11 Sep 2008 16:54:55 Z
Received: from [192.168.1.47] ([71.105.40.117]) by vms173003.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with 
          ESMTPA id <[EMAIL PROTECTED]> for
[EMAIL PROTECTED]; Thu, 11 Sep 2008 11:51:52 -0500 (CDT) References: <[EMAIL PROTECTED]> 
            <[EMAIL PROTECTED]>
Reply-To: Ken Warner <[EMAIL PROTECTED]>
Sender: Discussion list for Java 2D API <[EMAIL PROTECTED]>
Subject: Re: [JAVA2D] Dynamics of acceleration of BufferedImages ("managed images") 
To: [EMAIL PROTECTED]
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
X-Antispam: No, score=0.0/5.0,
scanned in 0.056sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 
            - http://smfs.sf.net/
X-Brightmail-Tracker: AAAAAA==
X-MessageGate-spam: 120
X-Original-To: [EMAIL PROTECTED]

Dmitri Trembovetski wrote:
That's the idea. The developer shouldn't be worrying about this stuff, 
   it should work for most cases. For those cases where the user needs
tweaking or resource management there are APIs like setAcceleratedPriority 
   and the like.

------
That's exactly the kind of stuff what a real programmer should be worrying about. And what if someone (like me or the author of this thread) run into a case where it doesn't quite work the way we want it to? We're sc 



===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".


===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to