Talk:Bitmap

It seems quite a few of the examples don't fulfill the task. The task asks for 3 procedures, Create, Get, and Set, but only two or three of the examples have them.

Also, I'm kind of unclear on the "get the color" procedure. For example, C++ returns a boolean? I thought the point was to return the pixel's color? --Mbishop 08:02, 20 February 2009 (UTC)

The boolean return value indicates success. The C++ GetPixel routine returns the color by modifying three variables the caller passes into it. The alternative would be to return a special data type, or a packed integer. Many C++ environments have the special datatype, such as Win32's RGBTRIPLE, RGBQUAD and COLORREF, but it's not strictly C++, and they're not really necessary. And returning a packed integer would require the caller to do their own processing. Using pointers or references as arguments is a common idiom in C++. However, I can add another C++ example that provides those three types as arguments to SetPixel and return values for GetPixel, and throws exceptions on failure instead of returning false. --Short Circuit 09:00, 20 February 2009 (UTC)

What is unclear to me is, can we use the existing bitmap image services of the language, or should we implement it from scratch using e.g. arrays? In RapidQ, I used QCanvas object. It has built-in methods for filling image, for drawing pixel and for reading pixel color, so there is no need to define any procedures. Many BASIC versions write directly to display hardware (e.g. in DOS or when using OpenGL or DirectX). Can this be used or should we have an off-screen image storage? --PauliKL 16:31, 20 February 2009 (UTC)

I would say it is OK to use device contexts, hardware buffers etc. So long you can implement the task from this category. However it could become quite tricky when it comes to digital filtration and other image processing techniques, because drawing contexts are usually oriented only to rendering. --Dmitry-kazakov 20:24, 20 February 2009 (UTC)

I would argue that it's appropriate to use any and every OS-specific support libraries, as long as it's not to the exclusion of other approaches. I don't think "exclusion of external libraries" is idiomatic to any language that supports them.

As for issues surrounding drawing contexts...I only have experience with graphics programming with GDI on Win32, but DCs there can be attached to memory buffers for offscreen rendering; It was likely essential for double-buffering on early graphics hardware with limited onboard memory. I expect most languages support similar mechanisms one way or another.--Short Circuit 04:38, 21 February 2009 (UTC)

I believe it's ok, until you can manipulate the buffers (basically, peeking and poking pixels some way, i.e. if you can do a "get pixel" and a "put pixel"), so that you can implement filters or whatever else, using the same buffer or another one as output. I was thinking about Perl and ImageMagick or Perl and Imglib... I believe also the main aim is to provide a framework for algorithms that manipulates data that can be thought as images, and so shown. --ShinTakezou 14:51, 21 February 2009 (UTC)

Interface vs Implementation

I noticed that Mbishop separated Modula-3's interface from its implementation last night. I think that's actually a very good idea, and should be done for any language where it's considered best practice. --Short Circuit 17:22, 23 February 2009 (UTC)

About Fortran I gave up; separating interface and implementation would mean to make the whole stuff a lot longer; and it would make sense if one wants to give the compiled code (while not undisclosing source) and make in the same time people to use the library. --ShinTakezou 23:53, 27 March 2009 (UTC)

Amount of comments

This is in particular related to J section. I completely agree that everybody has his own style of documenting the code, and J particularly favors brevity. However, in my opinion, for someone new in J extra comments could be quite helpful, and the purpose of this site is to show how to solve simple tasks.

So, I'd appreciate opinions about what is, in practice, a good level of commenting here for such a language.

A good comment could succinctly convey the purpose of the verb, and even help catch errors in the implementation, which may go unnoticed even with some examples of use. Without phrases like "For the basic bitmap structure, this way to store data is likely the most convenient and natural for manipulating with J." one could wonder why this particular data structure was chosen for the task in hand. Avmich 17:57, 29 August 2009 (UTC)